DPoP Mengikat Access Token OAuth ke Kunci Client

Bearer access token dapat digunakan oleh pihak mana pun yang memperoleh token tersebut dan mampu menyajikannya ke resource server. TLS melindungi token saat melewati koneksi yang diautentikasi dengan benar, tetapi tidak mengubah sifat bearer itu setelah token mencapai endpoint, log, process, browser context, atau lokasi penyimpanan lain.

Demonstrating Proof of Possession (DPoP), yang ditetapkan dalam RFC 9449, menambahkan binding berbasis kunci pada layer application protocol. Client membuat asymmetric key pair lalu menandatangani DPoP proof JWT. Authorization server dapat mengikat access token yang diterbitkan ke public key yang direpresentasikan oleh proof tersebut. Resource server kemudian mewajibkan token sekaligus proof valid yang dibuat dengan private key pasangannya.

Token yang dihasilkan bersifat sender-constrained, bukan credential bearer yang bebas dipindahkan. Batasannya spesifik: token saja tidak cukup. DPoP tidak membuat pencurian token mustahil, tidak membuktikan host client bebas kompromi, dan tidak menggantikan authorization policy OAuth lainnya.

Binding direpresentasikan oleh key thumbprint

DPoP proof membawa public key client dalam protected header jwk. Saat authorization server menerbitkan DPoP-bound access token, authorization data token tersebut diasosiasikan dengan public key. Untuk JWT access token, RFC 9449 menetapkan claim cnf yang memuat jkt, yaitu JWK SHA-256 thumbprint dari kunci tersebut.

Relasinya dapat disederhanakan menjadi:

private key client
       |
       v
DPoP proof bertanda tangan ---- public JWK ----+
                                             |
                                             v
                                      JWK thumbprint
                                             |
                                             v
                                  access token cnf.jkt

Private key tidak dikirim di dalam proof. Signature menunjukkan kontrol atas private key, sedangkan public JWK memberi verifier material untuk memverifikasi signature dan menghitung thumbprint.

Di resource server, penerimaan token dan penerimaan DPoP proof merupakan pemeriksaan yang saling terkait. Proof yang ditandatangani kunci lain tidak memenuhi sender constraint hanya karena signature-nya valid secara kriptografis.

Setiap proof terikat pada satu HTTP request

DPoP proof bukan client certificate yang dapat dipakai ulang. Bentuknya adalah JWT untuk operasi HTTP tertentu. Claim di dalamnya mencakup htm untuk HTTP method, htu untuk target URI, iat untuk issuance time, dan jti sebagai identifier unik. Proof yang dikirim bersama access token juga memuat ath, yaitu hash dari access token.

Field tersebut mengikat proof ke lebih dari sekadar kunci:

proof signature
  + HTTP method
  + target URI
  + issuance time
  + unique identifier
  + access-token hash

Verifier memeriksa nilai-nilai tersebut sesuai aturan RFC 9449. Proof yang tertangkap untuk satu target bukan signature generik yang dapat ditempelkan begitu saja ke method atau URI lain. Nilai ath juga mengikat protected-resource proof ke access token tertentu yang disajikan bersamanya.

Perbandingan URI perlu ditangani secara cermat. DPoP menetapkan pembentukan dan perbandingan nilai htu, termasuk perlakuan terhadap komponen query dan fragment. Implementasi sebaiknya mengikuti aturan protocol tersebut, bukan memakai rutinitas URL normalization lain yang diam-diam mengubah identitas request yang ditandatangani.

Freshness membatasi replay tetapi membutuhkan state atau policy verifier

Signature valid tidak membuat DPoP proof berlaku selamanya. Verifier mengevaluasi iat terhadap rentang waktu yang diterima dan dapat memakai jti untuk mendeteksi penggunaan ulang sesuai replay policy yang diterapkan.

Hal ini membentuk batas operasional. Acceptance window yang pendek mengurangi masa guna proof yang tertangkap, sedangkan replay detection pada banyak instance resource server dapat membutuhkan shared state atau pembagian state yang konsisten. Deployment yang hanya memverifikasi signature tetapi mengabaikan freshness dan request binding membuang bagian penting dari konstruksi DPoP.

DPoP juga mendukung nonce yang diberikan server. Authorization server atau resource server dapat mewajibkan nonce dan mengembalikan nilai baru untuk proof berikutnya. Client menempatkan nilai itu pada claim nonce. Mekanisme ini memungkinkan server meminta freshness berdasarkan material yang dibuat server, bukan hanya clock dan identifier milik client.

Dukungan nonce menambah request sequencing dan retry behavior yang harus ditangani client sesuai protocol. Nonce tidak menggantikan pemeriksaan claim proof lainnya.

Token issuance dan resource access memakai proof yang berkaitan

DPoP dapat muncul pada dua boundary OAuth yang berbeda. Saat memperoleh token, client mengirim DPoP proof ke authorization server. Proof tersebut memungkinkan server mengikat token yang dihasilkan ke public key client.

Saat mengakses protected resource, client membuat proof lain untuk resource request lalu mengirim access token menggunakan authorization scheme DPoP. Resource server memverifikasi token, proof, dan key binding di antara keduanya.

Kedua proof itu tidak dapat dipertukarkan karena HTTP target, method, timestamp, identifier, serta persyaratan token hash-nya berbeda. Memakai ulang proof untuk token endpoint pada API endpoint seharusnya gagal dalam pemeriksaan request binding.

Pemisahan ini juga menjaga batas otoritas. Authorization server memutuskan token yang diterbitkan dan mencatat key binding. Resource server menegakkan binding tersebut ketika mengotorisasi akses ke resource miliknya.

DPoP membatasi penggunaan token, bukan integritas software client

Jika malware dapat memanggil signing operation milik client yang sah, private key yang non-exportable atau dilindungi dengan cara lain belum tentu mencegah request berbahaya. DPoP membuktikan bahwa request ditandatangani dengan kunci yang terikat; DPoP tidak melakukan attestation atas intent software yang meminta signature.

Demikian pula, client yang menyimpan private key exportable di samping access token dapat kehilangan kedua artefak dalam kompromi yang sama. Penyerang yang memegang keduanya dapat membuat proof baru sampai kontrol lain menginvalidasi credential atau mencegah penggunaannya.

Key storage tetap menjadi bagian threat model. Platform keystore, hardware-backed key, process isolation, dan credential lifecycle control dapat mengubah tingkat kesulitan ekstraksi atau penyalahgunaan kunci, tetapi sifat tersebut berasal dari platform dan deployment, bukan dari DPoP sendiri.

Sender constraint tidak menggantikan audience atau authorization check

Resource server tetap memerlukan validasi access token biasa. Bergantung pada format token dan deployment, pemeriksaan itu dapat mencakup issuer, audience, expiry, signature, scope, dan authorization data lainnya. DPoP menambahkan bukti bahwa presenter mengontrol kunci yang menjadi binding token; DPoP tidak menentukan apakah token mengizinkan operasi bisnis yang diminta.

Pemisahan yang sama berlaku untuk token audience. htu pada proof mengikat proof ke HTTP URI, sedangkan token audience policy menentukan lokasi tempat token memang ditujukan untuk diterima. Kedua pemeriksaan dapat sama-sama diperlukan. Salah satunya tidak menyiratkan yang lain.

DPoP juga tidak menggantikan TLS. Protocol ini dirancang untuk digunakan bersama HTTPS. Transport security melindungi request dan response saat transit, sedangkan DPoP menangani masalah terpisah pada transfer bearer token dengan menambahkan sender constraint.

Proxy harus mempertahankan identitas request yang dipakai untuk verifikasi

Reverse proxy dan gateway dapat mempersulit validasi htu karena URI yang terlihat dari luar dapat berbeda dari target koneksi backend. Verifier membutuhkan representasi HTTP URI yang dapat dipercaya dan sama dengan yang digunakan client saat membuat proof.

Memercayai forwarding header yang dapat dikendalikan client tanpa pembatasan dapat memberi penyerang pengaruh terhadap rekonstruksi tersebut. Deployment di belakang proxy perlu menetapkan infrastruktur mana yang menyediakan scheme, host, dan request-target authoritative, membersihkan header pesaing, serta menjaga trust boundary itu konsisten dengan verifikasi DPoP.

Ini merupakan kelas masalah yang sama dengan security check lain yang bergantung pada identitas request eksternal: pemeriksaan kriptografis dapat benar sementara input yang direkonstruksi aplikasi keliru.

Key rotation mengubah sender constraint

Karena access token terikat ke public key tertentu, penggantian DPoP key tidak transparan bagi token yang sudah diterbitkan. Kunci baru menghasilkan JWK thumbprint berbeda sehingga tidak dapat memenuhi binding token lama.

Client memerlukan lifecycle behavior yang memperhitungkan token expiry sekaligus key rotation. Rotasi kunci dapat mengharuskan penerbitan bound token baru. Sebaliknya, mempertahankan kunci tanpa batas hanya agar token lama tetap dapat digunakan dapat memperpanjang umur key material melewati policy yang dimaksud.

Security boundary yang berguna bersifat sempit dan konkret: protected-resource request yang diterima harus membawa token yang berwenang serta DPoP proof baru dengan signing key yang cocok dengan sender constraint token tersebut. Batas yang presisi membuat DPoP berguna tanpa memberinya sifat yang sebenarnya berasal dari endpoint security, TLS, atau application authorization.

Referensi

Cybersecurity OAuth DPoP Access Token