OAuth Grant Types
Memahami Jenis-Jenis OAuth 2.0 Grant Type dan Kapan Menggunakannya
OAuth 2.0 merupakan standar otorisasi yang digunakan secara luas di dunia modern untuk memberikan akses terkontrol terhadap sumber daya (API) tanpa harus membagikan kredensial pengguna secara langsung. Dengan OAuth 2.0, aplikasi pihak ketiga (client) dapat mengakses data pengguna (resource owner) melalui authorization server dan resource server menggunakan access token.
Namun, tidak semua aplikasi berinteraksi dengan cara yang sama. OAuth 2.0 mengenal beberapa mekanisme berbeda untuk memperoleh token, yang disebut grant type. Setiap grant type memiliki tujuan, konteks, dan tingkat keamanan yang berbeda. Pemilihan grant type yang tepat sangat penting agar sistem tetap aman, efisien, dan sesuai dengan karakteristik client yang digunakan.
Artikel ini akan membahas seluruh jenis grant type dalam OAuth 2.0, beserta perbedaan dan konteks penggunaannya.
1. Authorization Code Grant
Konsep
Authorization Code Grant merupakan jenis grant yang paling umum digunakan, khususnya untuk aplikasi server-side (confidential client) yang mampu menyimpan rahasia (client secret) dengan aman. Dalam mekanisme ini, user akan diarahkan ke halaman login milik authorization server. Setelah berhasil login dan memberikan izin, authorization server akan mengirimkan authorization code ke client melalui redirect URI. Code tersebut kemudian ditukarkan oleh backend client dengan access token (dan opsional refresh token).
Alur Singkat
Pengguna diarahkan ke halaman login authorization server.
Setelah otorisasi berhasil, authorization server mengirimkan authorization code ke client melalui redirect URI.
Client (server-side) menukarkan code tersebut ke authorization server menggunakan
client_iddanclient_secretuntuk mendapatkan access token.
Kelebihan
Keamanan tinggi karena client secret disimpan di server.
Token tidak pernah terlihat oleh browser atau pihak ketiga.
Mendukung refresh token.
Kapan Digunakan
Web application dengan backend (misalnya Next.js, Laravel, Spring Boot, Go Fiber, dan lainnya).
Situasi di mana client dapat menjaga kerahasiaan client secret.
Contoh Kasus
Aplikasi web yang memungkinkan pengguna login menggunakan akun Google atau GitHub, di mana backend server bertanggung jawab menukarkan code dengan token.
2. Authorization Code Grant with PKCE (Proof Key for Code Exchange)
Konsep
PKCE (dibaca pixy) adalah pengembangan dari Authorization Code Grant yang ditujukan untuk public client, seperti aplikasi mobile (Android/iOS) dan SPA (Single Page Application), yang tidak dapat menyimpan client secret dengan aman.
Dalam skema PKCE, client akan membuat code verifier dan code challenge sebelum mengarahkan user untuk login. Ketika authorization server mengembalikan authorization code, client perlu mengirimkan code verifier yang sesuai untuk menukarkan code menjadi access token. Dengan cara ini, meskipun authorization code berhasil disadap, token tidak dapat diperoleh tanpa code verifier yang benar.
Alur Singkat
Client membuat code verifier dan code challenge (hash dari verifier).
User diarahkan ke halaman login authorization server dengan menyertakan code challenge.
Setelah otorisasi, authorization server mengirimkan authorization code.
Client menukarkan code tersebut ke access token dengan mengirim code verifier.
Kelebihan
Aman untuk public client karena tidak membutuhkan client secret.
Mencegah serangan authorization code interception.
Direkomendasikan oleh IETF untuk semua aplikasi baru.
Kapan Digunakan
Mobile app (Android/iOS).
Single Page Application (React, Vue, Angular, dan sejenisnya).
Public client yang tidak dapat menyimpan client secret.
Contoh Kasus
Aplikasi mobile yang melakukan login menggunakan OAuth Google, di mana proses otorisasi dilakukan melalui browser internal.
3. Client Credentials Grant
Konsep
Grant type ini digunakan dalam skenario tanpa pengguna (non-user), di mana aplikasi client berinteraksi langsung dengan authorization server untuk mendapatkan access token. Client mengirimkan permintaan token dengan client_id dan client_secret, dan authorization server akan mengembalikan access token tanpa memerlukan autentikasi pengguna.
Alur Singkat
Client mengirimkan request ke authorization server dengan
client_iddanclient_secret.Authorization server memverifikasi kredensial dan mengembalikan access token.
Kelebihan
Sederhana dan efisien untuk komunikasi antar sistem.
Tidak melibatkan pengguna.
Cocok untuk automasi, service account, atau integrasi antar microservices.
Kapan Digunakan
Komunikasi antar server (machine-to-machine).
API internal antar layanan.
Cron job, worker, atau backend job yang memerlukan autentikasi API.
Contoh Kasus
Sebuah backend service memanggil API pembayaran untuk memverifikasi status transaksi menggunakan kredensial service-nya sendiri.
4. Resource Owner Password Credentials (ROPC) Grant
Konsep
Pada grant type ini, pengguna memberikan username dan password-nya langsung ke aplikasi client. Client kemudian menukarkan kredensial tersebut dengan access token dari authorization server.
Model ini memberikan akses langsung tanpa proses redirect, tetapi memiliki risiko keamanan tinggi karena client harus memegang kredensial pengguna.
Alur Singkat
Client meminta username dan password pengguna.
Client mengirimkan kredensial tersebut ke authorization server.
Authorization server mengembalikan access token.
Kelebihan
Implementasi sederhana.
Tidak memerlukan browser atau redirect flow.
Kekurangan
Risiko keamanan tinggi karena password pengguna dapat disalahgunakan.
Tidak cocok untuk aplikasi publik atau pihak ketiga.
Tidak mendukung multi-factor authentication secara langsung.
Kapan Digunakan
Hanya untuk aplikasi internal yang sangat tepercaya.
Lingkungan tertutup, seperti CLI tool internal atau aplikasi legacy.
Catatan
ROPC saat ini dianggap deprecated dan tidak direkomendasikan untuk sistem modern.
5. Implicit Grant
Konsep
Implicit Grant awalnya dirancang untuk aplikasi client-side (SPA) agar dapat memperoleh access token langsung tanpa harus menukarkan authorization code. Token dikirim melalui fragment URI (#access_token) setelah pengguna login.
Namun, pendekatan ini memiliki kelemahan besar dari sisi keamanan karena access token dapat terekspos melalui URL atau log browser.
Kelebihan
Respons lebih cepat karena tidak ada proses pertukaran token tambahan.
Tidak membutuhkan backend server.
Kekurangan
Sangat rentan terhadap kebocoran token.
Tidak mendukung refresh token.
Tidak sesuai untuk sistem modern.
Status
Saat ini, Implicit Grant sudah deprecated dan telah digantikan oleh Authorization Code Grant dengan PKCE.
6. Device Code Grant
Konsep
Grant type ini digunakan untuk perangkat yang tidak memiliki kemampuan input yang memadai atau tidak memiliki browser, seperti Smart TV atau perangkat IoT. Dalam mekanisme ini, perangkat menampilkan kode khusus kepada pengguna. Pengguna kemudian membuka URL di perangkat lain (misalnya ponsel atau laptop) untuk login dan memasukkan kode tersebut. Setelah pengguna menyelesaikan proses otorisasi, authorization server memberikan access token ke perangkat.
Alur Singkat
Perangkat meminta device code dan menampilkannya ke pengguna.
Pengguna membuka URL login di perangkat lain dan memasukkan kode tersebut.
Authorization server memverifikasi dan mengirim access token ke perangkat.
Kapan Digunakan
Smart TV, console game, dan perangkat IoT.
Aplikasi CLI atau terminal yang tidak memiliki browser.
Contoh Kasus
Netflix atau YouTube di Smart TV menampilkan kode login yang dapat diaktivasi melalui browser di ponsel.
Tabel Ringkasan
Authorization Code
Web App (Server-side)
Ya
Tidak
Direkomendasikan
Authorization Code + PKCE
SPA, Mobile App
Ya
Ya
Direkomendasikan
Client Credentials
Server-to-Server
Tidak
Tidak
Direkomendasikan
Resource Owner Password (ROPC)
Legacy / Trusted Client
Ya
Tidak
Tidak Direkomendasikan
Implicit
SPA (lama)
Ya
Ya
Tidak Direkomendasikan
Device Code
IoT / Smart TV
Ya (melalui kode)
Ya
Direkomendasikan
Kesimpulan
Pemilihan grant type yang tepat sangat bergantung pada konteks aplikasi dan tingkat kepercayaannya. Untuk sistem modern, praktik terbaik yang direkomendasikan oleh IETF dan OpenID Foundation adalah:
Gunakan Authorization Code Grant dengan PKCE untuk aplikasi publik (mobile dan SPA).
Gunakan Authorization Code Grant standar untuk aplikasi dengan backend server.
Gunakan Client Credentials Grant untuk komunikasi antar sistem tanpa keterlibatan pengguna.
Hindari ROPC dan Implicit Grant karena alasan keamanan.
Gunakan Device Code Grant untuk perangkat dengan keterbatasan input.
OAuth 2.0 terus berkembang dengan berbagai ekstensi dan pembaruan (seperti OAuth 2.1) untuk memperkuat aspek keamanan. Memahami grant type secara menyeluruh menjadi dasar penting dalam merancang sistem autentikasi dan otorisasi yang aman serta sesuai standar industri.
Last updated