DPoP pada OAuth 2.0: Melindungi Token dari Penyalahgunaan

Access token OAuth 2.0 biasanya diperlakukan sebagai bearer token: siapa pun yang memilikinya dapat mencoba menggunakannya sampai token kedaluwarsa atau dicabut. Jika token tersalin ke log, laporan bug, penyimpanan yang tidak aman, atau perangkat yang telah disusupi, penyerang mungkin dapat memakainya dari tempat lain. Demonstrating Proof of Possession (DPoP) dirancang untuk mengurangi risiko tersebut dengan mengikat token pada pasangan kunci milik klien, sehingga token saja tidak cukup untuk mengakses API.

DPoP didefinisikan dalam RFC 9449. Mekanisme ini bekerja pada lapisan aplikasi dan dapat membantu mendeteksi penggunaan ulang bukti autentikasi. Namun, DPoP bukan pengganti HTTPS, kontrol akses, atau perlindungan perangkat klien.

Apa itu DPoP?

DPoP adalah mekanisme sender-constraining untuk token akses dan, dalam skenario yang didukung, token refresh OAuth. Klien membuat pasangan kunci publik dan privat. Saat meminta token atau memanggil API, klien mengirimkan JWT bukti DPoP yang ditandatangani dengan kunci privat. Server memeriksa bukti tersebut dan mengikat token yang diterbitkan ke kunci publik klien.

Akibatnya, pihak yang mencuri token tetapi tidak memiliki kunci privat yang sesuai akan lebih sulit menggunakannya. Kunci privat tidak dikirim ke server; server hanya membutuhkan materi kunci publik dan bukti yang dapat diverifikasi.

Bagaimana alur kerjanya?

1. Klien menyiapkan kunci. Aplikasi membuat atau menggunakan pasangan kunci yang sesuai, idealnya menyimpan kunci privat di penyimpanan terlindungi yang tersedia pada platform.
2. Klien meminta token. Permintaan ke server otorisasi menyertakan header DPoP berisi JWT bukti yang ditandatangani. Bukti memuat klaim seperti metode HTTP, URI target, waktu pembuatan, dan ID unik.
3. Server mengikat token. Jika valid dan kebijakan server mengizinkan, server mengeluarkan token yang terikat pada sidik jari kunci publik klien. Respons biasanya menggunakan jenis token DPoP, bukan Bearer.
4. Klien memanggil API. Setiap permintaan ke resource server menyertakan token akses dan bukti DPoP baru yang sesuai dengan permintaan tersebut.
5. API memverifikasi bukti. Server memeriksa tanda tangan, ikatan kunci dengan token, metode dan URI, waktu, serta apakah bukti pernah digunakan. Jika pemeriksaan gagal, permintaan ditolak.

Bukti untuk permintaan API juga mengikat hash token akses melalui klaim ath. Dengan demikian, bukti tidak bisa sembarangan dipasangkan dengan token akses yang berbeda.

Informasi apa yang diperiksa server?

Implementasi perlu memvalidasi seluruh komponen, bukan sekadar memastikan JWT memiliki tanda tangan yang valid.

• htm dan htu: metode HTTP dan URI target harus sesuai dengan permintaan sebenarnya.
• iat dan jti: waktu bukti harus berada dalam jendela yang diterima, dan ID uniknya membantu mendeteksi pemutaran ulang.
• Kunci publik: tanda tangan harus cocok dengan kunci dalam bukti, lalu kunci tersebut harus sesuai dengan ikatan yang tercatat pada token.
• ath: untuk akses resource, hash harus sesuai dengan token akses yang dikirim.
• Nonce bila diwajibkan: server dapat meminta nilai nonce untuk mengurangi peluang bukti lama atau yang telah dipersiapkan sebelumnya diterima.

Untuk mencegah replay, server umumnya perlu menyimpan atau melacak ID bukti yang telah diterima selama jendela validitasnya. Pemeriksaan waktu saja tidak cukup: bukti yang sama dapat dikirim ulang beberapa kali selama masih dianggap baru jika tidak ada deteksi duplikasi.

DPoP dibandingkan bearer token dan mTLS

Bearer token sederhana dan didukung luas, tetapi siapa pun yang memperoleh token dapat mencoba menggunakannya. DPoP menambahkan bukti kepemilikan kunci pada lapisan aplikasi, sehingga pencurian token saja tidak selalu cukup. Sementara itu, mutual TLS (mTLS) mengikat penggunaan token pada sertifikat klien di lapisan transportasi dan sering lebih sesuai untuk layanan yang dapat mengelola sertifikat secara terpusat.

DPoP dapat berguna untuk aplikasi browser atau aplikasi yang berjalan pada perangkat pengguna ketika mTLS tidak praktis. Namun, pilihan tetap bergantung pada kemampuan klien, server otorisasi, API, pengelolaan kunci, dan kebutuhan operasional. Semua komponen dalam alur harus mendukung DPoP; menambahkan header dari klien saja tidak membuat token otomatis terlindungi.

Batas keamanan yang penting

DPoP tidak menjadikan aplikasi kebal terhadap serangan. Jika penyerang mengendalikan proses klien atau dapat meminta kunci privat menandatangani bukti secara sewenang-wenang, perlindungannya dapat berkurang. Skrip berbahaya yang berjalan dalam konteks aplikasi juga bisa menyalahgunakan sesi aktif. DPoP tidak menyediakan integritas penuh untuk seluruh isi permintaan HTTP, sehingga HTTPS tetap wajib.

Server juga perlu memastikan proxy dan gateway meneruskan informasi permintaan secara konsisten. Perbedaan normalisasi URI, penggunaan URL internal setelah reverse proxy, atau validasi yang tidak seragam dapat menyebabkan permintaan sah ditolak atau, lebih buruk, pemeriksaan dilewati. Hindari membuat pengecualian longgar hanya untuk mengatasi masalah kompatibilitas.

Checklist implementasi

1. Pastikan penyedia OAuth, pustaka klien, dan resource server mendukung RFC 9449 dengan cara yang kompatibel.
2. Lindungi kunci privat menggunakan fasilitas penyimpanan platform bila tersedia, dan rencanakan rotasi serta pemulihannya.
3. Validasi metode, URI, tanda tangan, ikatan kunci, waktu, ID unik, dan hash token pada setiap permintaan yang relevan.
4. Terapkan deteksi replay terdistribusi yang konsisten bila API berjalan pada beberapa instance.
5. Uji bukti yang kedaluwarsa, URI atau metode yang diubah, token dari kunci berbeda, nonce, dan bukti yang dikirim berulang.
6. Jangan mencatat token akses, JWT bukti lengkap, atau rahasia ke log aplikasi. Pantau alasan penolakan tanpa menyimpan data sensitif yang tidak diperlukan.
7. Sediakan perilaku gagal yang aman. Jangan diam-diam menurunkan token DPoP menjadi bearer token saat validasi gagal.

Untuk memahami token JWT yang digunakan dalam sejumlah alur autentikasi, baca juga panduan JWT di Nazuaf. Untuk detail normatif DPoP dan contoh alurnya, gunakan dokumen resmi RFC 9449 dari RFC Editor.

Kesimpulan

DPoP memperkuat OAuth 2.0 dengan mengikat token pada kunci klien dan meminta bukti kriptografis untuk penggunaannya. Mekanisme ini dapat mengurangi nilai token yang dicuri, terutama bila kunci privat tetap terlindungi dan server memvalidasi setiap bukti dengan benar. Keberhasilannya bergantung pada dukungan seluruh komponen, deteksi replay, pengelolaan kunci, serta penggunaan HTTPS dan kontrol keamanan lain. Terapkan DPoP sebagai satu lapisan pertahanan yang diuji secara menyeluruh, bukan sebagai pengganti keamanan aplikasi.