OAuth (Open Authorization) adalah standar otorisasi yang memungkinkan sebuah aplikasi (client) mengakses resource milik user yang berada di server lain tanpa harus mengetahui atau menyimpan username dan password user.

OAuth bukan authentication protocol, melainkan authorization framework. Artinya:

• OAuth menjawab: “bolehkah aplikasi A mengakses data B?”
• Bukan: “siapa user ini sebenarnya?” (itu ranah authentication, misalnya OpenID Connect)

Masalah yang Ingin Diselesaikan OAuth #

Sebelum OAuth populer, pola yang umum adalah:

• User memberikan username & password ke aplikasi pihak ketiga
• Aplikasi pihak ketiga menyimpan credential tersebut

Masalah besar dari pendekatan ini:

1. Sangat tidak aman (password tersebar)
2. Tidak ada scope (akses all-or-nothing)
3. Tidak bisa dicabut sebagian (harus ganti password)
4. Tidak scalable untuk ekosistem aplikasi

OAuth hadir untuk:

• Memisahkan credential dan access
• Memberikan akses terbatas (scoped)
• Memungkinkan revocation kapan saja

Sejarah Singkat OAuth #

OAuth 1.0 (2007–2010) #

• Lahir dari komunitas (Twitter, Google, Yahoo)
• Distandardisasi sebagai OAuth 1.0 (RFC 5849)
• Fokus utama: keamanan request-level

OAuth 2.0 (2012 – sekarang) #

• Distandardisasi sebagai OAuth 2.0 (RFC 6749)
• Desain ulang total (tidak backward compatible)
• Fokus: kesederhanaan dan fleksibilitas
• Menjadi standar de-facto di industri

Catatan penting: OAuth 2.0 bukan “versi upgrade aman dari OAuth 1.0”, tapi framework baru dengan filosofi berbeda.

Fundamental Konsep OAuth #

Peran Utama (Roles) #

1. Resource Owner → User
2. Client → Aplikasi yang ingin mengakses data
3. Authorization Server → Server yang mengeluarkan token
4. Resource Server → Server penyimpan data (API)

Token #

• Access Token → Digunakan untuk mengakses API
• Refresh Token → Digunakan untuk meminta access token baru

Scope #

Mendefinisikan batasan akses, contoh:

• read_profile
• write_post
• email

OAuth 1.0 – Cara Kerja & Diagram #

Karakteristik OAuth 1.0 #

• Semua request ditandatangani (signed)
• Menggunakan consumer secret & token secret
• Aman walaupun tanpa HTTPS (secara teori)
• Implementasi sangat kompleks

Diagram Alur OAuth 1.0 #

[User]
   |
   | 1. Request Token
   v
[Client] ------------------> [Authorization Server]
   |        (signed request)
   |
   | 2. Redirect user
   v
[User] ---- login & approve ----> [Authorization Server]
   |
   | 3. Verifier
   v
[Client] ------------------> [Authorization Server]
   |        (signed request)
   |
   | 4. Access Token
   v
[Client] ------------------> [Resource Server]
            (signed request)

OAuth 2.0 – Cara Kerja & Diagram #

Karakteristik OAuth 2.0 #

• Mengandalkan HTTPS sebagai lapisan keamanan utama
• Request tidak disigned (cukup pakai token)
• Lebih sederhana dan fleksibel
• Mendukung banyak grant type / flow

Authorization Code Flow (paling umum) #

[User]
   |
   | 1. Redirect ke login
   v
[Client] ------------------> [Authorization Server]
   |
   | 2. User login & consent
   v
[User] ---- approve ----> [Authorization Server]
   |
   | 3. Authorization Code
   v
[Client] ------------------> [Authorization Server]
   |        (code + client_secret)
   |
   | 4. Access Token
   v
[Client] ------------------> [Resource Server]
            (Bearer Token)

Catatan PKCE (Best Practice Modern) #

• Menghindari pencurian authorization code
• Wajib untuk mobile & SPA

Perbedaan Fundamental OAuth 1.0 vs OAuth 2.0 #

Nilai Penting OAuth #

1. Keamanan credential user
2. Delegated access tanpa berbagi password
3. Fine-grained permission (scope)
4. Revocation & expiry token
5. Fondasi ekosistem API modern

Tanpa OAuth:

• Tidak ada Google Login
• Tidak ada GitHub OAuth
• Tidak ada integrasi SaaS modern

OAuth vs Metode Lain #

OAuth vs Basic Auth #

OAuth vs API Key #

OAuth vs JWT Custom Login #

• OAuth lebih standar & interoperable
• JWT custom cocok untuk internal system

Kelebihan dan Kekurangan OAuth #

Kelebihan #

1. Standar industri
2. Aman untuk third-party integration
3. Flexible flow
4. Scalable

Kekurangan #

1. Kompleks jika salah desain
2. Banyak implementasi salah kaprah
3. Overkill untuk sistem kecil

Best Practice #

Gunakan OAuth 2.0 + PKCE #

• Terutama untuk mobile & SPA

Jangan Gunakan Implicit Flow #

• Sudah deprecated secara praktik

Scope Sekecil Mungkin #

• Jangan beri * atau all-access

Access Token Short-Lived #

• 5–15 menit ideal

Refresh Token Rotation #

• Cegah replay attack

Pisahkan Authorization Server & Resource Server #

• Secara logical, minimal

Jangan Gunakan OAuth untuk Authentication Saja #

• Gunakan OpenID Connect jika butuh identitas user

Penutup #

OAuth adalah fondasi keamanan integrasi modern. Memahami sejarah, filosofi, dan perbedaannya—terutama antara OAuth 1.0 dan 2.0—akan mencegah kesalahan desain yang sering terjadi, seperti:

• Menganggap OAuth = login
• Menggunakan flow yang salah
• Memberi scope berlebihan

OAuth yang dipahami dengan benar bukan hanya soal token, tapi soal trust, boundary, dan responsibility dalam sistem terdistribusi.