Buana Cyber Security Knowledge

OAuth token theft prevention adalah serangkaian kontrol keamanan untuk mencegah access token/refresh token dicuri, dipakai ulang (replay), atau disalahgunakan untuk mengakses API atas nama pengguna. Karena token pada praktiknya bertindak seperti “kunci sementara”, kebocoran kecil saja (misalnya lewat XSS, log, atau penyimpanan yang salah) dapat berujung pada pengambilalihan akun (account takeover) dan akses data sensitif.

Di artikel ini, kita fokus pada pencegahan defensif yang bisa diterapkan di aplikasi web, mobile, dan backend: mulai dari pemilihan flow OAuth yang tepat, hardening penyimpanan token, hingga pemantauan dan respons insiden.

Mengapa pencurian OAuth token sangat berbahaya?

Berbeda dengan password yang biasanya harus diverifikasi ulang dan bisa dilindungi dengan MFA, token OAuth sering kali cukup digunakan sekali untuk mengakses API sampai token kedaluwarsa. Jika access token dicuri, pelaku bisa memanggil endpoint API, mengekspor data, atau melakukan aksi atas nama pengguna sesuai scope yang diberikan.

Risikonya meningkat ketika:

• Access token berumur panjang.
• Refresh token tidak diputar (rotation) dan bisa digunakan berulang.
• Token disimpan di tempat yang mudah diakses JavaScript (misalnya localStorage) pada aplikasi web yang rentan XSS.
• Token tercatat di log, URL, atau error report.
• Redirect URI dan konfigurasi client OAuth longgar sehingga memungkinkan pengalihan token.

Jenis token yang perlu Anda lindungi

Untuk konteks pencegahan, pahami peran token berikut:

• Access token: digunakan aplikasi untuk mengakses resource server (API). Biasanya berumur pendek.
• Refresh token: digunakan untuk mendapatkan access token baru. Ini biasanya lebih sensitif karena masa berlakunya lebih panjang.
• ID token (OIDC): berisi klaim identitas untuk proses autentikasi. Jangan dipakai sebagai token akses API.

Prinsip umumnya: semakin panjang masa berlaku, semakin besar dampak kebocoran—maka refresh token memerlukan kontrol ekstra.

12 praktik terbaik untuk OAuth token theft prevention

1) Gunakan flow yang tepat: Authorization Code + PKCE

Untuk aplikasi publik (SPA, mobile), gunakan Authorization Code Flow dengan PKCE. PKCE membantu memastikan kode otorisasi yang didapat tidak bisa ditukar menjadi token oleh pihak lain yang menyadap alur komunikasi.

Hindari flow yang tidak lagi direkomendasikan untuk skenario modern (misalnya Implicit Flow pada SPA), karena meningkatkan risiko paparan token.

2) Terapkan redirect URI yang ketat dan tervalidasi

Kesalahan konfigurasi redirect URI adalah sumber insiden yang sering. Pastikan:

• Hanya mengizinkan redirect URI yang terdaftar persis (exact match), bukan wildcard berlebihan.
• Menggunakan HTTPS dan domain yang benar-benar Anda kuasai.
• Mencegah open redirect di aplikasi Anda (validasi parameter redirect internal).

Tujuannya: mencegah token atau authorization code “mendarat” di endpoint milik pihak yang tidak sah.

3) Lindungi dari CSRF dengan parameter state dan sesi yang benar

Dalam OAuth/OIDC, parameter state berperan penting untuk mencegah CSRF dan memastikan respons login terkait dengan permintaan yang benar. Pastikan state:

• Acak, sulit ditebak, dan unik per permintaan.
• Divalidasi saat callback.
• Terikat ke sesi pengguna (misalnya disimpan di server-side session).

Untuk OIDC, gunakan juga nonce agar ID token tidak bisa dipakai ulang di konteks berbeda.

4) Buat access token berumur pendek dan scope minimal

Access token sebaiknya short-lived (misalnya beberapa menit) untuk mengurangi jendela penyalahgunaan jika token bocor. Selain itu, batasi izin dengan:

• Least privilege: scope hanya yang benar-benar dibutuhkan.
• Pemisahan scope sensitif (misalnya ekspor data) agar memerlukan persetujuan/step-up tambahan.
• Validasi audience (aud) agar token hanya valid untuk API yang dituju.

5) Amankan refresh token: rotation dan deteksi reuse

Jika arsitektur Anda menggunakan refresh token, terapkan:

• Refresh token rotation: setiap penggunaan refresh token menghasilkan refresh token baru.
• Reuse detection: jika refresh token lama dipakai lagi, anggap sebagai indikasi kompromi dan lakukan revocation sesi terkait.

Langkah ini efektif untuk memotong serangan “token replay” pada refresh token.

6) Pilih strategi penyimpanan token yang aman (web, SPA, mobile)

Kesalahan umum adalah menyimpan access token/refresh token di tempat yang mudah dicuri.

• Aplikasi web tradisional: pertimbangkan menyimpan token di server (backend) dan gunakan cookie sesi HttpOnly untuk browser.
• SPA: minimalkan penyimpanan token jangka panjang di browser. Jika memungkinkan, gunakan pola Backend-for-Frontend (BFF) agar token tidak perlu berada di JavaScript.
• Mobile: simpan token di penyimpanan aman OS (misalnya Keychain/Keystore) dan hindari menulis token ke log.

Jika Anda harus memakai cookie, pastikan cookie diberi atribut HttpOnly, Secure, dan kebijakan SameSite yang sesuai untuk menekan risiko pencurian lewat XSS dan penyalahgunaan lintas situs.

7) Minimalkan risiko XSS karena XSS adalah jalur pencurian token paling umum

Banyak kasus pencurian token pada web terjadi karena XSS yang memungkinkan skrip berbahaya membaca token (terutama jika token disimpan di localStorage/sessionStorage) atau mengirim permintaan API atas nama korban.

• Sanitasi dan encoding output (terutama konten yang berasal dari pengguna).
• Gunakan framework dan mekanisme templating yang aman secara default.
• Terapkan Content Security Policy (CSP) untuk mengurangi peluang eksekusi skrip tidak sah.
• Audit dependensi dan terapkan pembaruan keamanan rutin.

8) Jangan pernah menaruh token di URL atau membiarkannya masuk ke log

Token yang muncul di URL dapat bocor melalui history browser, referer header, proxy, atau tool analytics. Selain itu, token juga sering “tanpa sengaja” masuk ke:

• Log aplikasi (request/response logging).
• APM dan error tracking.
• Network debugging capture.

Terapkan kebijakan redaction untuk header Authorization, parameter sensitif, dan payload tertentu. Prinsipnya: token tidak boleh dapat diakses oleh sistem yang tidak perlu.

9) Pastikan validasi token di API ketat (issuer, audience, signature, expiry)

Di resource server (API), lakukan verifikasi menyeluruh sebelum mengizinkan akses:

• Validasi signature dan algoritma yang diizinkan.
• Validasi iss (issuer) dan aud (audience).
• Validasi exp, nbf, dan clock skew yang wajar.
• Periksa scope/role sesuai endpoint.

Validasi yang longgar dapat membuat token dari lingkungan lain (misalnya staging) diterima di produksi, atau token untuk layanan berbeda diterima oleh API Anda.

10) Pertimbangkan penguatan “token proof-of-possession” untuk mencegah replay

Secara default, banyak access token bersifat “bearer”: siapa pun yang memegangnya dapat memakainya. Untuk mengurangi risiko replay, pertimbangkan mekanisme yang mengikat token pada klien:

• DPoP (Demonstration of Proof-of-Possession) untuk mengikat token ke kunci milik klien pada permintaan HTTP.
• mTLS pada skenario tertentu untuk mengikat token ke sertifikat klien.

Opsi ini terutama relevan untuk integrasi antar layanan, aplikasi dengan tingkat risiko tinggi, atau akses ke data yang sangat sensitif.

11) Terapkan revocation, logout yang benar, dan kontrol sesi

Token theft prevention juga membutuhkan kemampuan memutus akses saat ada indikasi insiden:

• Sediakan endpoint revocation (sesuai dukungan authorization server) dan gunakan saat logout atau saat risiko terdeteksi.
• Batasi jumlah sesi aktif per user bila sesuai kebutuhan bisnis.
• Gunakan step-up authentication untuk aksi sensitif (misalnya ubah email, ekspor data) agar token saja tidak cukup.

12) Monitoring dan deteksi anomali penggunaan token

Pencegahan tidak selalu sempurna, jadi deteksi cepat sangat penting. Implementasikan:

• Alert untuk penggunaan token dari lokasi atau perangkat yang tidak biasa.
• Deteksi pola token replay (token yang sama dipakai dari IP/ASN berbeda dalam waktu singkat).
• Rate limiting dan proteksi API gateway untuk mengurangi dampak otomatisasi.
• Log keamanan yang terstruktur (tanpa token), agar investigasi dan korelasi insiden efektif.

Gabungkan dengan prosedur respons insiden: rotasi kredensial, revoke token, reset sesi, dan komunikasi ke pengguna bila diperlukan.

Checklist cepat implementasi (ringkas)

• Authorization Code + PKCE untuk SPA/mobile.
• Redirect URI exact match, tanpa wildcard longgar.
• state dan nonce wajib, tervalidasi.
• Access token short-lived, scope minimal, aud ketat.
• Refresh token rotation + reuse detection.
• Hindari penyimpanan token di localStorage; pertimbangkan BFF.
• HttpOnly/Secure/SameSite cookie bila memakai cookie.
• CSP + mitigasi XSS kuat.
• Redaction token dari log/APM/error tracking.
• Monitoring anomali dan rencana revocation.

FAQ: OAuth Token Theft Prevention

Apa penyebab paling umum token OAuth dicuri?

Yang paling sering adalah XSS pada aplikasi web (token tersimpan di tempat yang bisa dibaca JavaScript), kebocoran token ke log/analytics, serta konfigurasi OAuth yang longgar seperti redirect URI yang tidak ketat. Faktor lain termasuk perangkat pengguna terinfeksi malware atau penggunaan jaringan yang tidak aman tanpa kontrol tambahan.

Lebih aman simpan token di localStorage atau cookie?

Secara umum, menyimpan token di localStorage meningkatkan dampak jika terjadi XSS karena skrip berbahaya bisa membaca token. Cookie bisa lebih aman bila dikonfigurasi dengan HttpOnly dan Secure (sehingga tidak dapat dibaca JavaScript dan hanya terkirim lewat HTTPS). Namun cookie juga perlu mitigasi CSRF (misalnya SameSite yang tepat dan/atau token CSRF) tergantung desain aplikasi.

Berapa lama sebaiknya umur access token?

Tidak ada angka tunggal untuk semua sistem, tetapi praktik umum adalah beberapa menit untuk menekan jendela penyalahgunaan. Semakin sensitif data dan semakin tinggi risiko klien, semakin pendek umurnya. Jika access token dibuat pendek, pastikan mekanisme pembaruan (misalnya refresh token yang aman atau BFF) juga kuat.

Apakah JWT selalu aman untuk access token?

JWT bisa aman jika diverifikasi dengan benar (signature, issuer, audience, expiry) dan jika klaim serta scope dirancang dengan baik. Namun JWT yang dicuri tetap bisa disalahgunakan sampai kedaluwarsa. Jadi keamanan bukan hanya format token, tetapi juga umur token, penyimpanan, mitigasi XSS/CSRF, dan kemampuan revocation/monitoring.

Kapan perlu mempertimbangkan DPoP atau mTLS?

Pertimbangkan DPoP atau mTLS saat Anda perlu mengurangi risiko token replay secara signifikan, misalnya untuk API finansial, data kesehatan, atau integrasi antar layanan dengan risiko tinggi. Mekanisme ini menambah kompleksitas, jadi biasanya dipakai untuk sistem yang membutuhkan tingkat jaminan lebih tinggi daripada bearer token standar.