OAuth 2.0 dari Nol sampai Produksi: Konsep, Flow, PKCE, dan Praktik Aman

OAuth 2.0 dari Nol sampai Produksi: Konsep, Flow, PKCE, dan Praktik Aman

12/11/2025 • Security • By TryzTech Team
SecurityOAuth2AuthenticationAuthorizationAPI

OAuth 2.0 adalah standar de-facto untuk delegasi akses di web modern. Hampir semua aplikasi besar memakainya: login dengan Google, GitHub, atau Microsoft, akses API third‑party, integrasi SaaS, sampai mobile apps. Namun, banyak developer masih bingung: OAuth 2.0 itu autentikasi atau otorisasi? Kenapa ada banyak flow? Kenapa harus PKCE? Kapan pakai refresh token? Artikel ini membahas semuanya dari dasar sampai praktik aman di production.

Fokus tulisan ini adalah pemahaman konsep, memilih flow yang tepat, dan strategi keamanan yang benar. Kamu akan melihat peran-peran dalam OAuth 2.0, cara kerja token, perbedaan flow untuk web, mobile, dan machine‑to‑machine, serta checklist yang bisa langsung dipakai saat implementasi.

Daftar Isi

Apa itu OAuth 2.0?

OAuth 2.0 adalah protokol untuk delegasi akses. Artinya, user bisa memberi izin kepada aplikasi pihak ketiga untuk mengakses resource tertentu tanpa membagikan password. Misal: aplikasi kalender meminta akses baca ke Google Calendar, atau tools CI/CD mengambil repo private GitHub tanpa tahu passwordmu.

Bayangkan OAuth 2.0 seperti kartu akses hotel. Kamu (resource owner) memberi izin aplikasi (client) untuk menggunakan kartu akses agar bisa masuk ke kamar tertentu (resource). Kartu akses itu adalah access token. Hotel (authorization server) yang mengeluarkan kartu dan memastikan izinmu benar. Dengan analogi ini, jelas bahwa kartu akses bukan bukti identitas, tetapi bukti izin.

Use case umum OAuth 2.0:

  • Login sosial (dengan OIDC): Google, GitHub, Microsoft.
  • Integrasi API: menghubungkan CRM dengan email marketing.
  • Aplikasi mobile yang mengakses data user.
  • Service-to-service di microservices.

Autentikasi vs Otorisasi: Kenapa Banyak Salah Kaprah

  • Autentikasi (Authentication): memastikan “siapa kamu”.
  • Otorisasi (Authorization): memastikan “kamu boleh akses apa”.

OAuth 2.0 fokus pada otorisasi. Ketika kamu melihat fitur “Login dengan Google”, di balik layar sering digunakan OAuth 2.0 plus OpenID Connect. OAuth 2.0 memberikan akses token untuk API, sedangkan OIDC memberikan ID Token berisi informasi identitas.

Kesalahan umum: menganggap access token sebagai bukti identitas. Padahal access token adalah bukti izin akses ke resource, bukan bukti siapa pemiliknya. Untuk autentikasi, gunakan OIDC agar aman dan standar.

Komponen & Peran dalam OAuth 2.0

Ada empat peran utama:

  1. Resource Owner: user pemilik data (misal kamu).
  2. Client: aplikasi yang meminta akses (misal aplikasi kalender).
  3. Authorization Server: server yang mengeluarkan token (misal Google Authorization Server).
  4. Resource Server: server yang menyimpan data dan menerima access token (misal Google Calendar API).

Gambaran alur sederhana:

  1. Client meminta izin ke Authorization Server.
  2. User login dan memberi consent.
  3. Authorization Server mengeluarkan token.
  4. Client memanggil Resource Server menggunakan token.
  5. Resource Server memvalidasi token lalu memberikan data.

Scope menentukan batas akses. Contoh: read:profile, read:calendar, write:calendar. User akan melihat scope ini di halaman consent. Semakin sempit scope, semakin aman dan lebih mudah diyakinkan user.

Prinsip penting:

  • Terapkan least privilege: hanya minta scope yang benar-benar dibutuhkan.
  • Gunakan scope granular agar user paham apa yang diizinkan.
  • Simpan audit log agar tahu kapan scope disetujui.

Jenis Token: Access, Refresh, dan ID Token

  • Access Token: token utama untuk akses API. Umur pendek (misal 5–60 menit). Bisa berupa JWT atau opaque.
  • Refresh Token: token untuk mendapatkan access token baru tanpa login ulang. Umur panjang. Harus disimpan sangat aman.
  • ID Token: token identitas (OIDC). Berisi klaim seperti sub, email, name.

OAuth 2.0 secara standar tidak mewajibkan JWT. Kamu bisa memakai opaque token yang perlu di-introspect ke auth server. JWT lebih cepat di-validate, tapi perlu strategi rotation dan revocation yang jelas.

JWT vs Opaque Token + Validasi yang Benar

JWT (JSON Web Token) bisa diverifikasi secara lokal dengan public key sehingga cepat dan skalabel. Namun, jika ada token yang harus dicabut, kamu perlu strategi tambahan (revocation list atau token blacklist). Opaque token lebih aman untuk revocation karena resource server harus menanyakan ke auth server lewat token introspection, tapi menambah latensi.

Kapan memilih apa?

  • JWT: cocok untuk sistem skala besar dengan kebutuhan latency rendah.
  • Opaque: cocok untuk sistem yang butuh kontrol revocation ketat.

Jika kamu memakai JWT, pastikan resource server memvalidasi:

  • Signature (public key yang benar).
  • Issuer (iss) sesuai auth server.
  • Audience (aud) sesuai API yang dipanggil.
  • Expiry (exp) belum lewat.
  • Not before (nbf) jika digunakan.

Jangan lupa menolak token yang tidak sesuai aud atau iss. Banyak insiden keamanan terjadi karena token diterima oleh service yang salah.

Authorization Code Flow (Standar untuk Web)

Ini flow paling umum dan direkomendasikan untuk aplikasi web dengan server backend.

Alur singkat:

  1. Client mengarahkan user ke Authorization Server dengan parameter client_id, redirect_uri, scope, state.
  2. User login dan memberi consent.
  3. Authorization Server mengirim authorization code ke redirect_uri.
  4. Client menukar code dengan access token di backend menggunakan client_secret.
  5. Client memakai access token untuk akses resource.

Flow ini aman karena client_secret tidak pernah dikirim ke browser. Selain itu, code hanya berlaku singkat sehingga lebih tahan terhadap penyadapan.

Parameter penting:

  • state: token acak untuk mencegah CSRF.
  • redirect_uri: harus sesuai dengan yang terdaftar.
  • scope: daftar izin yang diminta.
  • code_challenge: jika menggunakan PKCE.

Contoh request authorization:

GET /authorize?response_type=code&client_id=abc&redirect_uri=https%3A%2F%2Fapp.com%2Fcallback&scope=read%3Aprofile&state=xyz

Contoh exchange token di backend:

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https%3A%2F%2Fapp.com%2Fcallback&client_id=abc&client_secret=SECRET

PKCE: Wajib untuk Mobile dan SPA

PKCE (Proof Key for Code Exchange) adalah extension untuk Authorization Code Flow agar aman dipakai di public clients (mobile app, SPA) yang tidak bisa menyimpan client secret.

Alur PKCE:

  1. Client membuat code_verifier random.
  2. Client membuat code_challenge = hash dari code_verifier.
  3. Saat request authorization, kirim code_challenge.
  4. Saat exchange token, kirim code_verifier.
  5. Authorization Server memverifikasi bahwa code_verifier cocok.

Manfaat PKCE: mencegah serangan interception pada authorization code. Tanpa PKCE, attacker yang mencuri code bisa menukarkannya menjadi token. Dengan PKCE, code tidak berguna tanpa code_verifier.

Di SPA, gunakan Authorization Code + PKCE dan simpan access token di memory (bukan localStorage) untuk mengurangi risiko XSS. Banyak tim memilih pola BFF (Backend for Frontend) agar token disimpan di server dan browser hanya memegang session cookie yang aman.

Client Credentials Flow (Machine-to-Machine)

Flow ini dipakai ketika tidak ada user, misal komunikasi antar service backend atau scheduled job. Client menggunakan client_id dan client_secret untuk meminta access token langsung.

Kelebihan:

  • Sederhana dan cepat.
  • Cocok untuk service‑to‑service.

Kekurangan:

  • Tidak ada konteks user.
  • Semua akses atas nama aplikasi.

Untuk microservices, kamu bisa menambahkan aud atau scope yang spesifik agar setiap service hanya bisa mengakses endpoint tertentu.

Contoh request:

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=abc&client_secret=SECRET&scope=read:reports

Device Authorization Flow (Login di Perangkat Terbatas)

Dipakai di perangkat yang input‑nya terbatas seperti Smart TV, IoT, atau CLI. Flow ini memberi user kode verifikasi dan URL untuk login di device lain.

Alur singkat:

  1. Client minta device_code dan user_code ke auth server.
  2. User membuka URL di perangkat lain dan memasukkan user_code.
  3. Client polling token endpoint sampai user selesai login.

Ini membuat login tetap aman tanpa harus mengetik password di perangkat terbatas. Flow ini sangat ideal untuk CLI tools developer karena login tetap aman walau tidak ada browser built‑in.

Implicit Flow: Kenapa Ditinggalkan

Implicit Flow dulu dipakai untuk SPA agar token bisa langsung dikirim ke browser. Tapi flow ini rentan:

  • Access token muncul di URL (bisa tertangkap lewat logs atau history).
  • Tidak ada refresh token yang aman.
  • Lebih rentan terhadap token leakage.

Sekarang rekomendasinya adalah Authorization Code + PKCE untuk SPA dan mobile. Jadi, kalau kamu masih pakai implicit flow, sebaiknya migrasi.

Strategi Penyimpanan Token per Platform

Cara menyimpan token sangat menentukan tingkat keamanan aplikasi. Prinsip utamanya: hindari tempat yang mudah diakses skrip berbahaya.

Web (server‑rendered):

  • Simpan refresh token di server.
  • Browser hanya menerima session cookie dengan HttpOnly, Secure, dan SameSite.
  • Access token bisa dipakai di server untuk memanggil API downstream.

SPA (single‑page app):

  • Simpan access token di memory (runtime) agar hilang saat refresh.
  • Jangan simpan refresh token di localStorage.
  • Pertimbangkan BFF agar token disimpan server‑side.

Mobile:

  • Gunakan secure storage (Keychain/Keystore).
  • Jangan log token ke console.
  • Aktifkan proteksi OS‑level jika tersedia.

CLI/IoT:

  • Simpan token di keychain atau encrypted file.
  • Batasi scope dan umur token.
  • Gunakan device flow agar login aman.

Refresh Token: Umur Panjang, Rotasi, dan Revocation

Refresh token memungkinkan aplikasi mendapatkan access token baru tanpa login ulang. Tapi token ini sangat sensitif. Praktik aman:

  • Simpan refresh token di server, bukan di browser.
  • Gunakan rotating refresh token: setiap pemakaian refresh token menghasilkan refresh token baru.
  • Terapkan deteksi reuse untuk mencegah pencurian token.
  • Batasi umur refresh token (misal 30 hari) dan gunakan idle timeout.

OAuth 2.0 menyediakan endpoint revocation untuk mencabut token. Gunakan saat user logout atau mencabut akses aplikasi. Selain itu, endpoint introspection membantu resource server mengecek token opaque atau token yang perlu validasi ulang.

Gunakan revocation ketika:

  • User logout dari semua device.
  • Aplikasi dicurigai disalahgunakan.
  • Scope berubah atau akses dicabut.

Observability & Monitoring

Keamanan OAuth 2.0 tidak hanya soal desain, tapi juga soal operasional. Beberapa hal yang wajib dipantau:

  • Jumlah token issuance per client dan per user.
  • Error rate pada endpoint /token dan /authorize.
  • Anomali lokasi login atau device baru.
  • Deteksi reuse refresh token (indikasi token bocor).
  • Latency introspection jika memakai opaque token.

Gunakan logging yang cukup untuk audit, namun jangan pernah menyimpan token mentah di log. Simpan identifier atau hash token jika perlu tracking.

Kesalahan Umum & Cara Menghindari

Beberapa kesalahan yang sering terjadi di implementasi OAuth 2.0:

  • Menganggap access token sebagai identitas: solusinya gunakan OIDC dan validasi ID token.
  • Redirect URI terlalu longgar: pakai exact match, jangan wildcard.
  • Menyimpan token di localStorage: ganti dengan memory atau BFF.
  • Tidak memvalidasi state: rawan CSRF.
  • Menggunakan implicit flow: migrasi ke Authorization Code + PKCE.

Selain itu, jangan lupa menguji skenario edge case: token expired, refresh token reuse, revoke token saat user logout, dan token dengan aud yang salah. Banyak bug keamanan muncul dari jalur error yang jarang diuji.

Best Practice Keamanan OAuth 2.0

Berikut checklist keamanan utama:

  1. Selalu gunakan HTTPS untuk semua endpoint.
  2. Validasi state untuk mencegah CSRF.
  3. Gunakan PKCE untuk public clients (mobile/SPA).
  4. Batasi scope sesuai kebutuhan.
  5. Gunakan short‑lived access token.
  6. Implement refresh token rotation.
  7. Validasi redirect URI secara ketat (exact match).
  8. Hindari implicit flow.
  9. Gunakan OIDC untuk autentikasi.
  10. Audit log semua token issuance dan revocation.

Tambahan penting:

  • Proteksi XSS dan CSRF di aplikasi web.
  • Jangan simpan token di localStorage jika memungkinkan.
  • Gunakan SameSite cookies untuk session berbasis server.
  • Rate limit endpoint token untuk mencegah brute force.
  • Rotasi client secret secara berkala.

Checklist Implementasi Production

Agar implementasimu siap production, pastikan poin ini terpenuhi:

  • Sudah memilih flow yang tepat untuk platform.
  • redirect_uri tidak boleh wildcard.
  • Token disimpan dengan aman (server‑side atau secure storage di mobile).
  • Ada mekanisme revoke token ketika user logout.
  • Error handling jelas (invalid_grant, invalid_scope).
  • Monitoring untuk anomali login dan token reuse.
  • Dokumentasi scope dan consent yang rapi untuk user.

Checklist tambahan yang sering terlupakan:

  • Konfigurasi CORS yang ketat untuk endpoint auth.
  • Gunakan key rotation untuk signing JWT.
  • Pastikan waktu server sinkron (NTP) agar validasi exp dan nbf akurat.
  • Logging yang memadai namun tanpa menyimpan token mentah.
  • Uji alur refresh token dan revoke secara otomatis di CI.

Kesimpulan

OAuth 2.0 adalah fondasi utama untuk akses API modern. Dengan memahami peran, flow, dan token, kamu bisa memilih strategi yang tepat untuk web, mobile, maupun machine‑to‑machine. Kunci utamanya adalah keamanan: gunakan PKCE untuk public clients, batasi scope, terapkan refresh token rotation, dan selalu gunakan HTTPS.

Kalau tujuannya autentikasi, jangan hanya pakai OAuth 2.0 murni—tambahkan OpenID Connect agar kamu mendapat ID token yang aman dan standar. Dengan praktik ini, aplikasi kamu akan lebih aman, scalable, dan siap production.

Resources

Diskusi & Komentar

Punya pertanyaan soal OAuth 2.0, pengalaman integrasi dengan provider tertentu, atau tips tambahan? Tulis di komentar ya! Tim TryzTech siap bantu diskusi dan berbagi praktik terbaik supaya integrasimu makin aman dan rapi.