Saya sedang mengimplementasikan OAuth 2.0 JWT access_token di server otentikasi saya. Tapi, saya tidak mengerti apa perbedaan antara audklaim JWT dan nilai client_idheader HTTP. Apakah mereka sama? Jika tidak, dapatkah Anda menjelaskan perbedaan antara keduanya?

Kecurigaan saya adalah itu audharus merujuk ke server sumber daya, dan client_idharus merujuk ke salah satu aplikasi klien yang dikenali oleh server otentikasi (yaitu aplikasi web, atau aplikasi iOS).

Dalam kasus saya saat ini, server sumber daya saya juga merupakan klien aplikasi web saya.

Ternyata, kecurigaan saya benar. audKlaim audiens di JWT dimaksudkan untuk merujuk ke Server Sumber Daya yang harus menerima token.

Seperti ini posting hanya menempatkan:

Penonton token adalah penerima token yang dimaksud.

Nilai audiens adalah string - biasanya, alamat dasar sumber daya yang diakses, seperti https://contoso.com.

Dalam client_idOAuth mengacu pada aplikasi klien yang akan meminta sumber daya dari Server Sumber Daya.

Aplikasi Klien (misalnya aplikasi iOS Anda) akan meminta JWT dari Server Otentikasi Anda. Dengan demikian, ia meneruskannya client_iddan client_secretbersama dengan kredensial pengguna apa pun yang mungkin diperlukan. Server Otorisasi memvalidasi klien menggunakan client_iddan client_secretdan mengembalikan JWT.

JWT akan berisi audklaim yang menentukan Server Sumber Daya mana JWT valid untuk. Jika audberisi www.myfunwebapp.com, tetapi aplikasi klien mencoba menggunakan JWT www.supersecretwebapp.com, maka akses akan ditolak karena Resource Server akan melihat bahwa JWT tidak dimaksudkan untuk itu.

audKlaim JWT (Audience)

Menurut RFC 7519 :

Klaim "aud" (audiens) mengidentifikasi penerima yang menjadi tujuan JWT. Setiap prinsipal yang dimaksudkan untuk memproses JWT HARUS mengidentifikasi dirinya sendiri dengan nilai dalam klaim audiens. Jika prinsipal yang memproses klaim tidak mengidentifikasi dirinya dengan nilai dalam klaim "aud" saat klaim ini ada, JWT HARUS ditolak. Dalam kasus umum, nilai "aud" adalah larik string peka huruf besar / kecil, masing-masing berisi nilai StringOrURI. Dalam kasus khusus ketika JWT memiliki satu audiens, nilai "aud" MUNGKIN berupa string peka huruf besar kecil yang berisi nilai StringOrURI. Interpretasi nilai-nilai khalayak umumnya berlaku khusus untuk aplikasi. Penggunaan klaim ini OPSIONAL.

audKlaim Audience ( ) seperti yang didefinisikan oleh spesifikasi bersifat umum, dan khusus untuk aplikasi. Tujuan penggunaan adalah untuk mengidentifikasi penerima token yang dituju. Yang dimaksud penerima adalah khusus aplikasi. Nilai audiens bisa berupa daftar string, atau bisa berupa string tunggal jika hanya ada satu audklaim. Pencipta token tidak memberlakukan yang auddivalidasi dengan benar, tanggung jawab berada pada penerima untuk menentukan apakah token tersebut harus digunakan.

Apa pun nilainya, ketika penerima memvalidasi JWT dan ingin memvalidasi bahwa token dimaksudkan untuk digunakan untuk tujuannya, itu HARUS menentukan nilai apa dalam audmengidentifikasi dirinya sendiri, dan token hanya boleh memvalidasi jika ID yang dinyatakan penerima adalah hadir dalam audklaim. Tidak masalah jika ini adalah URL atau string khusus aplikasi lainnya. Misalnya, jika sistem saya memutuskan untuk mengidentifikasi dirinya auddengan string: api3.app.commaka sistem seharusnya hanya menerima JWT jika audklaim berisi api3.app.comdaftar nilai audiensnya.

Tentu saja penerima dapat memilih untuk mengabaikannya aud, jadi ini hanya berguna jika penerima menginginkan validasi positif bahwa token dibuat khusus untuknya.

Penafsiran saya berdasarkan spesifikasinya adalah bahwa audklaim tersebut berguna untuk membuat JWT yang dibuat khusus yang hanya valid untuk tujuan tertentu. Untuk satu sistem, ini mungkin berarti Anda ingin token valid untuk beberapa fitur, tetapi tidak valid untuk yang lain. Anda dapat menerbitkan token yang dibatasi hanya untuk "audiens" tertentu, sambil tetap menggunakan kunci dan algoritme validasi yang sama.

Karena pada umumnya, JWT dibuat oleh layanan tepercaya, dan digunakan oleh sistem tepercaya lainnya (sistem yang tidak ingin menggunakan token yang tidak valid), sistem ini hanya perlu mengoordinasikan nilai yang akan mereka gunakan.

Tentu saja, audsepenuhnya opsional dan dapat diabaikan jika kasus penggunaan Anda tidak menjaminnya. Jika Anda tidak ingin membatasi token untuk digunakan oleh audiens tertentu, atau tidak ada sistem Anda yang benar-benar akan memvalidasi audtoken tersebut, maka itu tidak berguna.

Contoh: Akses vs. Segarkan Token

Satu contoh yang dibuat-buat (namun sederhana) yang dapat saya pikirkan adalah mungkin kita ingin menggunakan JWT untuk mengakses dan menyegarkan token tanpa harus menerapkan kunci enkripsi dan algoritme terpisah, tetapi hanya ingin memastikan bahwa token akses tidak akan divalidasi sebagai token penyegaran, atau sebaliknya -versa.

Dengan menggunakan audkita dapat menentukan klaim refreshuntuk token penyegaran dan klaim accessuntuk token akses setelah membuat token ini. Saat permintaan dibuat untuk mendapatkan token akses baru dari token penyegaran, kita perlu memvalidasi bahwa token penyegaran adalah token penyegaran asli. The audvalidasi seperti dijelaskan di atas akan memberitahu kita apakah tanda itu sebenarnya refresh valid token mencari khusus untuk klaim refreshdi aud.

ID Klien OAuth vs. audKlaim JWT

Client ID OAuth sama sekali tidak terkait, dan tidak memiliki korelasi langsung dengan audklaim JWT . Dari perspektif OAuth, token adalah objek buram.

Aplikasi yang menerima token ini bertanggung jawab untuk mem-parsing dan memvalidasi arti dari token ini. Saya tidak melihat banyak manfaat dalam menentukan ID Klien OAuth dalam audklaim JWT .

Jika Anda datang ke sini mencari OpenID Connect (OIDC): OAuth 2.0! = OIDC

Saya menyadari bahwa ini diberi tag untuk oauth 2.0 dan BUKAN OIDC, namun sering kali ada penggabungan antara 2 standar karena kedua standar dapat menggunakan JWT dan audklaim. Dan satu (OIDC) pada dasarnya merupakan perpanjangan dari yang lain (OAUTH 2.0). (Saya menemukan pertanyaan ini sendiri untuk mencari OIDC.)

Token Akses OAuth 2.0 ##

Untuk token OAuth 2.0 Access , jawaban yang ada sudah cukup memadai. Selain itu, berikut adalah satu bagian yang relevan dari Kerangka Kerja OAuth 2.0 (RFC 6749)

Untuk klien publik yang menggunakan aliran implisit, spesifikasi ini tidak menyediakan metode apa pun bagi klien untuk menentukan untuk apa token akses diberikan kepada klien.
...
Mengautentikasi pemilik sumber daya kepada klien berada di luar cakupan spesifikasi ini. Spesifikasi apa pun yang menggunakan proses otorisasi sebagai bentuk autentikasi pengguna akhir yang didelegasikan ke klien (misalnya, layanan masuk pihak ketiga) TIDAK HARUS menggunakan alur implisit tanpa mekanisme keamanan tambahan yang akan memungkinkan klien untuk menentukan apakah akses tersebut token dikeluarkan untuk penggunaannya (misalnya, audiens- membatasi token akses).

Token ID OIDC ##

OIDC memiliki Token ID selain token Akses. Spesifikasi OIDC secara eksplisit tentang penggunaan audklaim dalam Token ID. ( openid-connect-core-1.0 )

aud
DIBUTUHKAN. Audiens yang menjadi tujuan Token ID ini. Ini HARUS berisi client_id OAuth 2.0 dari Pihak Pengandal sebagai nilai audiens. Ini MUNGKIN juga berisi pengenal untuk audiens lain. Dalam kasus umum, nilai aud adalah larik string peka huruf besar / kecil. Dalam kasus khusus umum ketika ada satu audiens, nilai aud MUNGKIN berupa string peka huruf besar / kecil.

selanjutnya OIDC menentukan azpklaim yang digunakan sehubungan dengan audketika audmemiliki lebih dari satu nilai.

azp
OPSIONAL. Pihak yang berwenang - pihak yang menerbitkan Token ID. Jika ada, itu HARUS berisi ID Klien OAuth 2.0 pihak ini. Klaim ini hanya diperlukan jika Token ID memiliki nilai audiens tunggal dan audiens tersebut berbeda dari pihak yang berwenang. MUNGKIN disertakan meskipun pihak resminya sama dengan penonton tunggal. Nilai azp adalah string case sensitif yang berisi nilai StringOrURI.

Meskipun ini sudah tua, saya pikir pertanyaan itu valid bahkan sampai hari ini

Kecurigaan saya adalah bahwa aud harus merujuk ke server sumber daya, dan client_id harus merujuk ke salah satu aplikasi klien yang dikenali oleh server otentikasi

Ya, aud harus mengacu pada pihak yang mengonsumsi token. Dan client_id mengacu pada pihak yang memperoleh token.

Dalam kasus saya saat ini, server sumber daya saya juga merupakan klien aplikasi web saya.

Dalam skenario OP, aplikasi web dan server sumber daya keduanya milik pihak yang sama. Jadi ini berarti klien dan audiens menjadi sama. Tetapi mungkin ada situasi di mana hal ini tidak terjadi.

Pikirkan tentang SPA yang menggunakan sumber daya yang dilindungi OAuth. Dalam skenario ini SPA adalah klien. Sumber daya yang dilindungi adalah audiens token akses.

Skenario kedua ini menarik. Ada draf yang berfungsi bernama " Indikator Resource untuk OAuth 2.0 " yang menjelaskan di mana Anda dapat menentukan audiens yang dituju dalam permintaan otorisasi Anda. Jadi token yang dihasilkan akan dibatasi untuk audiens yang ditentukan. Selain itu, Azure OIDC menggunakan pendekatan serupa yang memungkinkan pendaftaran sumber daya dan mengizinkan permintaan autentikasi berisi parameter sumber daya untuk menentukan token akses audiens yang dituju. Mekanisme tersebut memungkinkan adpotations OAuth memiliki pemisahan antara klien dan pihak yang mengonsumsi token (audiens).