OAuth2

Apa itu OAuth2?

OAuth2 adalah kerangka kerja otorisasi yang memungkinkan aplikasi pihak ketiga mendapatkan akses terbatas ke resource pengguna tanpa mengekspos kredensial pengguna. OAuth2 fokus pada otorisasi - bukan autentikasi.

Roles

Terdapat empat peran utama dalam OAuth2:

• Resource Owner: Entitas yang dapat memberikan akses ke resource yang dilindungi. Biasanya adalah pengguna akhir (end-user).
• Client: Aplikasi yang ingin mengakses resource atas nama resource owner. Bisa berupa web app, mobile app, atau server-side app.
• Authorization Server: Server yang mengeluarkan access token setelah berhasil mengautentikasi resource owner dan mendapatkan otorisasi. Bertanggung jawab atas login page, consent screen, dan manajemen token.
• Resource Server: Server yang menyimpan resource yang dilindungi dan menerima access token untuk memvalidasi permintaan akses. Biasanya adalah API backend.

Grant Types

OAuth2 mendefinisikan beberapa grant type (alur otorisasi):

Authorization Code Grant

Alur paling aman dan paling umum. Client mengarahkan pengguna ke authorization server, yang setelah login memberikan authorization code ke client. Client kemudian menukarkan code tersebut dengan access token (via backend). Mendukung PKCE (Proof Key for Code Exchange) untuk mobile/public clients.

Implicit Grant

Alur legacy di mana access token dikembalikan langsung melalui URL fragment setelah redirect. Tidak lagi direkomendasikan karena risiko keamanan (token terekspos di URL riwayat browser). Digantikan oleh Authorization Code + PKCE.

Client Credentials Grant

Digunakan untuk komunikasi machine-to-machine (M2M). Client mengautentikasi dirinya sendiri (bukan atas nama pengguna) menggunakan client_id dan client_secret. Cocok untuk API internal, cron jobs, dan service backend.

Resource Owner Password Grant

Pengguna memberikan username/password langsung ke client, yang kemudian menukarkannya dengan access token. Hanya direkomendasikan untuk migrasi legacy atau aplikasi first-party yang sangat trusted. Risiko tinggi karena kredensial terekspos ke client.

Device Code Grant

Dirancang untuk perangkat dengan input terbatas (smart TV, IoT, terminal). Perangkat menampilkan kode yang harus dimasukkan pengguna di perangkat lain (laptop/HP) untuk login. Cocok untuk flow login di smart TV dan CLI tools.

Scopes

Scopes adalah mekanisme untuk membatasi akses token. Contoh scope: read:profile, write:posts, email, openid. Scope memungkinkan pengguna memberikan izin granular - misal "izinkan membaca profil tetapi tidak mengirim pesan".

Refresh Tokens

Refresh token adalah token jangka panjang yang digunakan untuk mendapatkan access token baru tanpa meminta pengguna login lagi. Access token biasanya memiliki masa berlaku pendek (15 - 60 menit), sementara refresh token bisa berlaku berhari-hari atau berminggu-minggu. Refresh token harus disimpan dengan aman di sisi server dan mendukung rotation (refresh token baru dikeluarkan setiap kali digunakan, yang lama dinonaktifkan).

OAuth2 vs OpenID Connect (OIDC)

OAuth2 adalah framework otorisasi - ia memberi akses ke resource. OpenID Connect adalah lapisan autentikasi di atas OAuth2 yang menambahkan ID Token (JWT) berisi identitas pengguna.

Praktik terbaik: Gunakan OIDC untuk login pengguna, OAuth2 untuk API authorization.

Security Considerations

Redirect URI Validation

Salah satu attack vector paling umum. Attacker dapat mencuri authorization code jika redirect URI tidak divalidasi ketat. Mitigasi: Authorization server harus memvalidasi redirect URI secara eksak (karakter per karakter). Jangan gunakan wildcard atau prefix matching longgar.

CSRF with State Parameter

Tanpa state parameter, attacker dapat memulai flow OAuth dan mengintersep hasilnya untuk mendapatkan akses. Mitigasi: Client harus mengirimkan parameter state yang unik dan random untuk setiap request, kemudian memvalidasinya ketika menerima callback. State parameter mencegah CSRF attack pada callback OAuth.

Additional Mitigations

• Gunakan PKCE untuk semua public clients (mobile, SPA).
• Enforce HTTPS untuk semua endpoint.
• Implementasikan token binding / DPoP (Demonstration of Proof-of-Possession).
• Rotasi refresh token secara periodik.
• Jangan gunakan Implicit Grant - gunakan Authorization Code + PKCE.
• Validasi aud (audience) pada access token di resource server.