Binding Sertifikat OAuth mTLS Memindahkan Bukti Token ke Koneksi TLS

Sebuah OAuth access token dapat lolos dari seluruh pemeriksaan sintaks dan kriptografi di resource server tetapi tetap belum cukup untuk memperoleh akses. Pada token yang terikat sertifikat mutual TLS, server juga memerlukan bukti dari koneksi TLS: client yang membawa token harus memiliki private key yang sesuai dengan sertifikat yang diasosiasikan dengan token tersebut.

Kondisi ini mengubah batas keamanan. Bearer token dapat digunakan oleh pihak yang memperoleh nilai token, dengan tetap tunduk pada pembatasan token lainnya. Token yang terikat sertifikat menambahkan syarat kepemilikan terpisah yang terhubung ke TLS client certificate. Token dan private key menjadi dua bagian dalam jalur otorisasi yang sama.

RFC 8705 menstandarkan model ini untuk OAuth 2.0. Mekanismenya lebih sempit daripada klaim umum bahwa mTLS membuat OAuth aman. Sertifikat dapat memiliki peran berbeda pada endpoint yang berbeda, dan peran tersebut perlu tetap dipisahkan pada implementasi maupun operasi.

Client authentication dan binding token adalah mekanisme terpisah

Mutual TLS dapat mengautentikasi OAuth client ke authorization server. RFC 8705 mendefinisikan metode berbasis PKI dan sertifikat self-signed untuk tujuan tersebut. Dalam alur itu, authorization server mengasosiasikan material sertifikat dengan client terdaftar dan memakai TLS client certificate sebagai bagian dari client authentication.

Certificate-bound access token menangani masalah yang berkaitan tetapi berbeda. Authorization server mengasosiasikan token yang diterbitkan dengan sertifikat yang dipakai client. Pada protected resource, client mengirim token melalui koneksi TLS yang saling terautentikasi dengan sertifikat yang sama. Resource server mengambil peer certificate dari lapisan TLS lalu memeriksa kecocokannya dengan binding sertifikat yang dibawa token atau diasosiasikan dengan token tersebut.

Kedua mekanisme ini saling melengkapi, tetapi RFC 8705 tidak mewajibkan keduanya digunakan bersama. Sertifikat dapat berfungsi sebagai proof of possession untuk bound token tanpa menjadi kredensial OAuth client. Perbedaan ini relevan bagi public client dan arsitektur yang menerapkan model kepercayaan berbeda antara client authentication dan penyajian token.

Untuk JWT access token, RFC 8705 mendefinisikan anggota x5t#S256 di dalam claim cnf. Nilainya merepresentasikan thumbprint SHA-256 yang di-encode dengan base64url dari sertifikat X.509 berformat DER. Authorization server juga dapat menyediakan informasi binding yang setara melalui token introspection alih-alih menanamkannya di dalam self-contained token.

Karena itu, keputusan resource server bukan sekadar “apakah PKI saya mempercayai sertifikat ini?” Pemeriksaan yang relevan untuk binding token adalah apakah sertifikat pada koneksi TLS ini merupakan sertifikat yang diasosiasikan dengan token.

Kepemilikan dibuktikan pada lapisan TLS

Private key tidak ikut dikirim bersama access token. Selama mutual TLS, client menyajikan sertifikat dan membuktikan kepemilikan private key yang sesuai sebagai bagian dari autentikasi TLS. Resource server kemudian menghubungkan fakta pada lapisan TLS tersebut dengan binding OAuth token.

Susunan ini membatasi satu failure mode tertentu pada bearer token. Menyalin nilai access token saja tidak cukup untuk memakai certificate-bound token yang enforcement-nya benar dari TLS client lain yang tidak memiliki bound private key.

Properti tersebut bergantung pada enforcement. Authorization server harus menerbitkan binding dengan benar, dan setiap protected resource yang menerima bound token harus membandingkannya dengan sertifikat dari koneksi TLS yang terautentikasi. Jika intermediary melakukan terminasi TLS, aplikasi di belakang intermediary tidak lagi mengamati sesi TLS client asli secara langsung. Deployment kemudian memerlukan mekanisme tepercaya untuk membawa informasi client certificate yang sudah terautentikasi melewati batas internal, atau pemeriksaan binding perlu dilakukan pada titik terminasi TLS.

Meneruskan sertifikat melalui HTTP header biasa tanpa mengendalikan pihak yang dapat mengatur header tersebut mengubah fakta yang telah diautentikasi transport menjadi input yang dapat dikendalikan penyerang. Reverse proxy dapat membawa metadata semacam ini dengan aman hanya ketika downstream service mempercayai proxy tersebut, akses langsung dibatasi, dan nilai metadata yang dikirim client tidak dapat melewati atau menimpa nilai dari proxy.

Token tidak dapat menentukan permintaan sertifikat pada initial TLS handshake

Salah satu batas deployment muncul dari urutan protokol. Permintaan awal server atas TLS client certificate terjadi selama TLS handshake. OAuth access token baru tiba setelahnya sebagai application data. Resource server karena itu tidak dapat memeriksa token terlebih dahulu lalu memakai token tersebut untuk menentukan apakah initial handshake yang sudah berjalan seharusnya meminta client certificate.

RFC 8705 menyatakan urutan ini secara eksplisit. Deployment dapat mewajibkan mutual TLS untuk seluruh resource pada sebuah listener, atau memisahkan traffic yang dilindungi mTLS ke hostname atau port tersendiri. Desain lain tetap mungkin, tetapi routing dan kebijakan TLS harus menyediakan sertifikat sebelum aplikasi mencoba melakukan pemeriksaan binding token.

TLS 1.3 memiliki mekanisme post-handshake client authentication ketika client menyatakan dukungannya. Kemampuan tersebut tidak menghapus batas deployment RFC 8705: RFC 8705 tidak menetapkan penggunaan post-handshake authentication untuk alur akses resource dengan certificate-bound token. Memperlakukan post-handshake authentication sebagai pengganti otomatis akan menambahkan perilaku di luar profil OAuth mTLS yang didefinisikan.

Masalah sequencing ini bersifat operasional, bukan kosmetik. Satu endpoint yang mencampur traffic bearer token biasa dengan traffic certificate-bound memerlukan strategi TLS yang eksplisit. Aplikasi tidak dapat menunda seluruh keputusan transport hingga pemrosesan OAuth selesai.

Kepercayaan sertifikat dan kesamaan sertifikat menjawab pertanyaan berbeda

Deployment mTLS tradisional sering menekankan validasi certificate chain: server menerima client certificate yang diterbitkan di bawah model kepercayaan tertentu lalu memetakan identitas sertifikat ke application principal. Certificate-bound OAuth token dapat memakai sertifikat dengan fungsi berbeda.

RFC 8705 mengizinkan mutual TLS pada resource server berfungsi murni sebagai proof of possession. Dalam kondisi itu, resource server tidak perlu memperlakukan certificate chain milik client sebagai pernyataan identitas yang berdiri sendiri. Server perlu memastikan TLS client membuktikan kepemilikan private key, kemudian mencocokkan sertifikat yang disajikan dengan binding token.

Perbedaan ini terlihat jelas pada sertifikat self-signed. Sertifikat self-signed dapat tidak sesuai sebagai kredensial identitas PKI umum, tetapi tetap menyediakan public key dan representasi sertifikat yang dapat menjadi target binding token. Keputusan otorisasi berasal dari token beserta pemeriksaan kepemilikan, bukan dari asumsi bahwa CA publik menjamin identitas client.

Implementasi perlu memisahkan jalur validasi tersebut secara eksplisit. Menerapkan syarat kepercayaan public PKI secara tidak sengaja pada desain proof-of-possession berbasis self-signed certificate dapat menolak client yang valid. Sebaliknya, menerima sembarang client certificate tanpa memeriksa binding token menghilangkan properti yang hendak diberikan oleh certificate-bound token.

Rotasi membatalkan binding ke sertifikat lama

Certificate-bound token terikat pada sertifikat tertentu, bukan hanya pada nama client yang abstrak. Saat client mengganti sertifikat, access token yang terikat ke sertifikat lama tidak dapat dipakai dengan sertifikat baru. RFC 8705 menyebut kondisi ini dapat ditangani serupa dengan token yang kedaluwarsa: client memperoleh access token baru yang terikat pada sertifikat baru lalu mengulangi resource request.

Perilaku tersebut menjadikan rotasi sertifikat bagian dari desain siklus hidup token. Deployment yang sering merotasi client certificate tetapi menerbitkan access token berumur panjang dapat memiliki periode ketika token yang secara waktu belum kedaluwarsa tidak lagi dapat dipakai setelah rotasi. Ini bukan cacat kriptografi; kondisi tersebut merupakan konsekuensi dari binding yang cukup spesifik untuk menolak sertifikat berbeda.

Spesifisitas yang sama juga memengaruhi incident response. Mencabut atau menghapus client certificate tidak secara otomatis mengubah setiap format token. Resource server tetap harus menegakkan binding sertifikat pada setiap request. Sebaliknya, kepemilikan private key dari sertifikat tidak memberikan otoritas OAuth tanpa batas: penyerang juga memerlukan token yang otorisasi dan binding-nya diterima oleh resource server.

Batas enforcement mencakup OAuth dan TLS

Certificate-bound access token sering disebut proof-of-possession token, tetapi bukti tersebut tidak seluruhnya berada di dalam token. Bukti penentu terbagi di antara beberapa lapisan. OAuth membawa grant otorisasi dan asosiasi sertifikat; TLS membuktikan kepemilikan private key yang sesuai pada koneksi yang dipakai untuk mengakses resource.

Pembagian ini merupakan batas implementasi utama. Token validator, TLS terminator, reverse proxy, dan resource server harus memiliki kesepakatan tentang lokasi client certificate diautentikasi serta lokasi binding diperiksa. Jika tanggung jawab tersebut terbagi di beberapa komponen, handoff internal menjadi bagian dari batas keamanan.

Properti yang dihasilkan bersifat spesifik: pencurian nilai token saja tidak cukup ketika protected resource benar-benar mewajibkan sertifikat yang terikat dan memverifikasi binding tersebut. Hal itu tidak menghapus kebutuhan atas otorisasi token, siklus hidup sertifikat, kepercayaan proxy, routing endpoint, atau kebijakan TLS. Kontrol tersebut tetap menjadi bagian terpisah dalam jalur request, sedangkan kekuatan binding sertifikat bergantung pada titik tempat seluruh bagian itu disatukan.