Pemeriksaan Audience JWT Menjaga Token di Batas Layanan yang Dituju

Signature JSON Web Token yang valid membuktikan hal yang terbatas: byte token ditandatangani dengan key yang diterima verifier dan tidak diubah setelahnya tanpa membuat signature menjadi tidak valid. Hasil itu tidak menetapkan bahwa token diterbitkan untuk layanan yang sedang menerimanya.

Perbedaan ini penting pada sistem tempat satu authority menerbitkan token bagi beberapa API, atau beberapa authority memakai key yang dapat dijangkau aplikasi melalui konfigurasi. Token dapat valid secara kriptografis tetapi berasal dari konteks keamanan yang berbeda. Claim iss dan aud memberi verifier input untuk menegakkan batas tersebut.

Verifikasi signature dan penerimaan token adalah keputusan terpisah

Pemrosesan JWT biasanya dimulai dengan parsing JOSE header, pemilihan algoritma dan key yang diizinkan, lalu verifikasi signature atas header dan payload yang telah di-encode. Signature yang lolos melindungi claim bertanda tangan dari perubahan yang tidak terdeteksi dalam konfigurasi trust yang dipilih.

Penerimaan oleh aplikasi masih memerlukan policy. Resource server biasanya perlu memastikan setidaknya bahwa token berasal dari issuer yang diharapkan, menyebut resource tersebut sebagai audience yang dituju, masih berada dalam rentang waktu yang diterima, dan membawa claim yang dibutuhkan untuk operasi yang diminta.

Memperlakukan keberhasilan signature sebagai seluruh keputusan otorisasi menyatukan pemeriksaan itu menjadi satu hasil kriptografis yang tidak memuat seluruh policy aplikasi.

Claim issuer menetapkan konteks authority

Registered claim iss mengidentifikasi principal yang menerbitkan JWT. Nilainya berupa string yang case-sensitive. Verifier yang dikonfigurasi untuk authority tertentu dapat membandingkan issuer token dengan nilai konfigurasi, bukan menerima issuer apa pun hanya karena key signature tersedia.

Pemilihan key dan validasi issuer memiliki fungsi berbeda. Key menunjukkan material kriptografis yang berhasil memverifikasi signature. Issuer menunjukkan konteks penerbitan yang memang dipercaya aplikasi untuk alur token tersebut.

Pemisahan ini juga relevan ketika key diambil dari JSON Web Key Set. Header kid dapat membantu memilih candidate key, tetapi kid bukan aturan otorisasi issuer. Key identifier yang cocok tidak menggantikan pemeriksaan issuer secara eksplisit.

Audience mengikat token ke penerima yang dituju

Registered claim aud mengidentifikasi penerima yang dituju untuk JWT. RFC 7519 mengizinkan claim ini berisi satu string audience atau array string. Ketika principal yang memproses JWT tidak mengidentifikasi dirinya dalam nilai aud saat claim tersebut tersedia, JWT harus ditolak.

Bayangkan dua API mempercayai token dari issuer yang sama:

issuer
  |
  +-- token A: aud = inventory-api
  |
  +-- token B: aud = billing-api

Jika kedua API hanya memeriksa issuer dan signature, token A dapat lolos dari dua pemeriksaan itu di billing API meskipun audience-nya menunjuk inventory API. Pemeriksaan audience memberi billing API aturan langsung untuk menolak penggunaan lintas layanan tersebut.

Nilai audience yang tepat merupakan bagian dari policy deployment. Bentuknya dapat berupa identifier, URI, atau string lain yang ditetapkan sistem otorisasi. Verifier sebaiknya membandingkannya dengan nilai yang dikonfigurasi untuk security domain miliknya, bukan memakai substring atau prefix matching yang longgar kecuali aturan pencocokan tersebut memang ditetapkan oleh protocol profile yang digunakan.

OAuth access token membawa persyaratan profile tersendiri

JWT adalah format token, bukan protokol kontrol akses yang lengkap. Deployment OAuth yang memakai JWT sebagai access token dapat menetapkan aturan claim dan validasi tambahan.

RFC 9068 mendefinisikan profile untuk OAuth 2.0 access token berformat JWT. Dalam profile tersebut, resource server memvalidasi token sesuai metadata issuer dan memeriksa bahwa claim aud memuat resource indicator yang cocok dengan identifier milik resource server. Profile itu juga mensyaratkan pemrosesan lain, termasuk validasi signature dan pemeriksaan terkait waktu.

Library JWT generik tidak dapat menentukan batas resource OAuth yang dituju hanya dari kriptografi. Aplikasi atau framework harus menyediakan expected issuer, audience, algoritma yang diizinkan, serta policy khusus profile yang berlaku.

Audience tidak menggantikan otorisasi

Audience yang benar menyatakan bahwa token ditujukan kepada suatu penerima. Nilai itu tidak menyatakan bahwa semua operasi pada penerima tersebut diizinkan.

Otorisasi dapat bergantung pada scope, role, entitlement, identitas subject, konteks tenant, kepemilikan resource, atau policy aplikasi lainnya. Claim tersebut membutuhkan validasi dan interpretasi sendiri. Sebagai contoh, token dengan aud = billing-api dapat ditujukan dengan benar ke layanan billing tetapi tidak memiliki izin untuk menerbitkan refund.

Boundary tersebut karena itu berlapis:

signature valid
    + issuer yang diharapkan
    + audience yang dituju
    + rentang waktu valid
    + claim otorisasi yang dibutuhkan
    + policy khusus request
    = candidate request dapat dilanjutkan

Setiap kondisi menjawab persoalan berbeda. Menghapus satu kondisi karena kondisi lain berhasil akan memperluas aturan penerimaan.

Token multi-audience memperluas kumpulan penerima

Sebuah token dapat menyebut lebih dari satu audience. Bentuk ini dapat tepat ketika protokol penerbitan memang membuat credential untuk beberapa penerima, tetapi konsekuensinya setiap penerima yang disebut masuk ke dalam kumpulan audience token tersebut.

Service sebaiknya tidak memasukkan dirinya ke konvensi audience bersama hanya demi menyederhanakan konfigurasi. Jika dua service memiliki boundary otorisasi yang berbeda secara material, identifier audience terpisah membuat reuse token yang tidak disengaja lebih mudah ditolak dan didiagnosis.

Gateway juga tidak otomatis menyelesaikan persoalan ini. Jika gateway memvalidasi token lalu meneruskan konteks identitas ke downstream, kontrak trust antara gateway dan backend menjadi boundary tersendiri. Jika backend menerima bearer token asli secara langsung, policy validasi token miliknya tetap harus sesuai dengan arsitektur dan tidak menganggap posisi jaringan sebagai bukti bahwa validasi sudah dilakukan.

Konfigurasi validasi adalah state yang sensitif terhadap keamanan

Expected issuer dan audience berada bersama konfigurasi keamanan penting lainnya. Default permisif seperti menerima audience apa pun, menonaktifkan pemeriksaan issuer, atau diam-diam memperlakukan expected value yang kosong sebagai tanpa batas mengubah trust boundary meskipun verifikasi signature tetap aktif.

Perubahan konfigurasi layak mendapat review yang sama dengan kode yang mengubah logika otorisasi. Log dapat mencatat kelas validasi yang gagal tanpa menulis bearer token itu sendiri. Field yang berguna mencakup identitas issuer terkonfigurasi, expected resource identifier, hasil validasi, dan request correlation identifier yang aman.

Bearer token perlu diperlakukan sebagai credential. Output diagnostik yang menyalin JWT lengkap ke log dapat mengekspos material otorisasi yang dapat digunakan kembali meskipun logika validasinya benar.

Trust token merupakan gabungan kondisi, bukan hasil signature

Signature JWT menyediakan integritas dan autentikasi signer relatif terhadap key yang dipilih. Penerimaan oleh service memerlukan pernyataan yang lebih sempit: token valid di bawah authority yang diharapkan, ditujukan kepada penerima ini, dapat diterima secara temporal, dan cukup untuk tindakan yang diminta.

Pemeriksaan issuer dan audience membuat dua bagian dari pernyataan tersebut menjadi policy eksplisit. Memisahkannya dari pemilihan key dan otorisasi membuat trust boundary terlihat dalam konfigurasi dan kode, sekaligus mencegah token yang valid secara kriptografis diperlakukan sebagai token yang berlaku universal di seluruh service.

References

Cybersecurity JWT OAuth Autentikasi