Di OpenID Connect, token akses memiliki waktu kedaluwarsa. Untuk aliran kode otorisasi, ini biasanya singkat (misalnya 20 menit) setelah itu Anda menggunakan token penyegaran untuk meminta token akses baru.

The ID token juga memiliki waktu kadaluwarsa. Pertanyaan saya adalah apa maksud dari ini?

Setiap waktu kedaluwarsa token ID kurang dari waktu kedaluwarsa token penyegaran akan berarti Anda pada akhirnya akan memiliki token ID yang kedaluwarsa, tetapi token akses yang valid.

Jadi, apakah Anda dimaksudkan untuk:

• berikan token ID Anda kedaluwarsa lebih lama dari token penyegaran kedaluwarsa, atau
• setel ke kedaluwarsa yang sama dengan token akses dan lakukan beberapa tindakan (apa?) saat kadaluwarsa, atau
• cukup gunakan token ID di klien Anda saat diterima, lalu abaikan waktu kedaluwarsa setelah itu?

Spesifikasi OpenID Connect hanya mengatakan bahwa saat memvalidasi token ID,

"The current time MUST be before the time represented by the exp Claim."

yang (mungkin) mendukung opsi ketiga di atas.

EDIT

Karena OpenID Connect dibangun di atas OAuth2, jawaban untuk pertanyaan tambahan di bawah ini dapat ditemukan dalam spesifikasi OAuth2 yang menyatakan,

expires_in
     RECOMMENDED.  The lifetime in seconds of the access token.

Pertanyaan terkait adalah ketika Anda menukar kode otorisasi untuk token, spesifikasi yang sama mengatakan Anda mungkin mendapatkan respons seperti:

{
 "access_token": "SlAV32hkKG",
 "token_type": "Bearer",
 "refresh_token": "8xLOxBtZp8",
 "expires_in": 3600,
 "id_token": "eyJhbG[...]"
}

Tapi apa hubungannya dengan "expires_in" dalam kasus ini? Token akses, token penyegaran, atau token ID?

(Sebagai informasi, IdentityServer3 menyetel ini ke waktu kedaluwarsa token akses).

Saya menjawab pertanyaan saya sendiri karena telah menemukan bahwa beberapa asumsi di balik pertanyaan saya salah, jadi lebih mudah untuk menjelaskannya di sini, daripada menulis ulang pertanyaannya.

Token ID dimaksudkan untuk membuktikan kepada Klien bahwa pengguna telah mengautentikasi, dan sebagai hasilnya.

Saat Klien menerima token ID, biasanya ia akan melakukan sesuatu seperti mengubahnya menjadi ClaimsIdentity, dan mempertahankannya, misalnya menggunakan cookie.

Token ID harus tidak kedaluwarsa pada saat ini digunakan (yang seharusnya, karena baru saja diterbitkan). Tetapi setelah ini tidak digunakan lagi, jadi tidak masalah jika kedaluwarsa saat pengguna masih memiliki sesi aktif. Klien memiliki informasi otentikasi yang dibutuhkan, dan pada gilirannya dapat memilih kebijakannya sendiri untuk berapa lama sesi berlangsung sebelum pengguna harus masuk lagi.

Asumsi saya yang salah ketika mengajukan pertanyaan adalah bahwa token ID dan token akses harus digunakan bersama, dan oleh karena itu keduanya harus memiliki tanggal kedaluwarsa yang valid. Ini salah karena berbagai alasan:

• Token ID hanya untuk mengautentikasi ke Klien (seperti yang dijelaskan di atas).
• Token akses tidak ada hubungannya dengan Klien. Mereka adalah untuk akses ke sumber daya dan Klien hanya menanganinya jika pada gilirannya perlu memanggil sumber daya.
• Sesuatu seperti aplikasi MVC atau WebForms mandiri hanya membutuhkan token ID. Jika tidak memanggil sumber daya eksternal, tidak ada yang dapat diberikan akses, jadi tidak ada token akses.

Saya harus menggali ini untuk alasan saya sendiri dan menulisnya, jadi saya akan memposting apa yang saya pelajari di sini ...

Pertama, saya akan menjawab pertanyaan dengan risiko menyatakan yang sudah jelas: Token ID tidak dapat dipercaya dan isinya harus diabaikan jika waktu saat ini lebih besar dari waktu kedaluwarsa. Jawaban penanya menyatakan bahwa setelah otentikasi awal pengguna, ID Token tidak digunakan lagi. Namun, karena Token ID ditandatangani oleh penyedia identitas, tentu saja dapat berguna kapan saja untuk memberikan cara yang andal dalam menentukan siapa pengguna ke layanan lain yang mungkin digunakan aplikasi. Menggunakan ID pengguna atau alamat email yang sederhana tidak dapat diandalkan karena dapat dengan mudah dipalsukan (siapa pun dapat mengirim alamat email atau ID pengguna), tetapi karena Token ID OIDC ditandatangani oleh server Otorisasi (yang biasanya juga memiliki keuntungan sebagai pihak ketiga), itu tidak dapat dipalsukan dan merupakan mekanisme otentikasi yang jauh lebih andal.

Misalnya, aplikasi seluler mungkin ingin dapat memberi tahu layanan backend siapa pengguna yang menggunakan aplikasi dan mungkin perlu melakukannya setelah periode singkat setelah otentikasi awal, di mana Token ID kedaluwarsa, dan karenanya, tidak dapat digunakan untuk mengautentikasi pengguna dengan andal.

Oleh karena itu, seperti token akses (digunakan untuk otorisasi - menentukan izin apa yang dimiliki pengguna) dapat diperbarui, dapatkah Anda menyegarkan Token ID (digunakan untuk otentikasi - menentukan siapa pengguna)? Menurut spesifikasi OIDC, jawabannya tidak jelas. Di OIDC / OAuth, ada tiga "aliran" untuk mendapatkan token, Alur Kode Otorisasi, aliran Implisit, dan aliran Hibrid (yang akan saya lewati di bawah karena merupakan varian dari dua lainnya).

Untuk aliran implisit di OIDC / OAuth, Anda meminta Token ID di titik akhir otorisasi dengan mengarahkan pengguna di browser ke titik akhir Otorisasi dan memasukkannya id_tokensebagai nilai response_typeparameter permintaan. Sebuah Implisit Arus Sukses Authentication Respon adalah DIBUTUHKAN untuk menyertakan id_token.

Untuk alur Kode Otentikasi , klien menentukan codesebagai nilai response_typeparameter permintaan saat mengarahkan pengguna ke titik akhir otorisasi. Tanggapan yang berhasil menyertakan kode otorisasi. Klien klien membuat permintaan ke titik akhir token dengan kode otorisasi dan, menurut Bagian Inti OIDC 3.1.3.3 Respons Token yang Berhasil , respons HARUS menyertakan Token ID .

Jadi untuk aliran mana pun, begitulah awalnya Anda mendapatkan Token ID, tetapi bagaimana Anda menyegarkannya? OIDC Bagian 12: Menggunakan Refresh Token memiliki pernyataan berikut tentang Respon Refresh Token:

Setelah validasi Refresh Token berhasil, isi respons adalah Token Response dari Bagian 3.1.3.3 kecuali bahwa itu mungkin tidak berisi id_token .

Ini mungkin tidak berisi Token ID dan karena tidak ada cara yang ditentukan untuk memaksanya memasukkan token ID, Anda harus berasumsi bahwa respons tidak akan berisi Token ID. Jadi secara teknis tidak ada cara khusus untuk "menyegarkan" Token ID menggunakan token penyegaran. Oleh karena itu, satu-satunya cara untuk mendapatkan Token ID baru adalah dengan memberi otorisasi ulang / mengautentikasi pengguna dengan mengarahkan pengguna ke titik akhir otorisasi dan memulai aliran implisit atau aliran kode otentikasi seperti yang dijelaskan di atas. Spesifikasi OIDC menambahkan promptparameter permintaan ke permintaan otorisasi sehingga klien dapat meminta agar server otorisasi tidak meminta pengguna dengan UI apa pun, tetapi pengalihan masih harus terjadi.

Jika saya mengerti dengan benar, menurut ini dan spesifikasi OpenID Connect Core 1.0 , token ID itu sendiri dapat disimpan dalam cookie sebagai mekanisme untuk mempertahankan sesi, dan dikirim dengan setiap permintaan otentikasi yang membutuhkan ke Klien. Klien kemudian dapat memverifikasi token ID baik secara lokal atau melalui titik akhir pemverifikasi Penyedia (jika disediakan, seperti yang dilakukan Google ). Jika token kedaluwarsa, token harus membuat permintaan autentikasi lain, kecuali kali ini dengan prompt=nonedi parameter URL. Pastikan juga untuk mengirimkan token ID yang sudah habis masa berlakunya dalam id_token_hintparameter, jika tidak, Penyedia dapat mengembalikan kesalahan.

Jadi, tampaknya wajar jika Token ID kedaluwarsa, tetapi prompt=nonememastikan token ID baru dapat diperoleh dengan lancar tanpa campur tangan pengguna (kecuali pengguna keluar dari OpenID tersebut).

Ini adalah maksud yang sama: Anda tidak dapat menggunakan id_tokensetelah kedaluwarsa. Perbedaan utamanya adalah an id_tokenmerupakan struktur data dan Anda tidak perlu memanggil server atau titik akhir apa pun, karena informasi tersebut dikodekan dalam token itu sendiri. Biasa access_tokenbiasanya merupakan artefak buram (seperti GUID).

Konsumen id_tokenharus selalu memverifikasi keabsahan (waktu) itu.

Saya tidak 100% akrab dengan IS, tapi saya rasa ini adalah bidang kenyamanan. Anda harus selalu memeriksa expklaimnya.

Kedaluwarsa hanyalah salah satu validasi. id_tokens juga ditandatangani secara digital dan itu juga merupakan validasi yang harus Anda lakukan.

Menyegarkan token berarti Anda dapat menggunakannya lagi untuk meminta sesuatu dari server otorisasi (dalam hal ini OP - Penyedia OpenID-Connect) MESKIPUN KETIKA PENGGUNA TIDAK MASUK. Anda biasanya mengizinkan ini untuk sumber daya terbatas saja, dan hanya setelah pengguna masuk dan diautentikasi setidaknya sekali. Token penyegaran itu sendiri juga harus dibatasi waktunya.

Dalam aliran implisit OIDC, Anda memanggil titik akhir Otorisasi,
dan menerima token ID sebagai respons bersama dengan semua cakupan dan di dalamnya semua info klaim.
Panggilan selanjutnya ke API dimaksudkan untuk dilakukan dengan aliran kode .
Aliran implisit dimaksudkan untuk mengaktifkan hanya javascript atau aplikasi khusus browser. Bukan aplikasi yang berinteraksi dengan server.
Jadi, meskipun ada cara untuk "menyegarkan" token ini, Anda tidak boleh - dari segi keamanan - membiarkannya hidup terlalu lama. Ini akan dicuri dan digunakan kembali oleh pengguna yang tidak sah yang meniru identitas tersebut. Anda harus memaksa login baru untuk itu.

Dalam alur kode, Anda memanggil titik akhir Otorisasi OP, dan menerima kode Otorisasi (juga disebut token otorisasi, atau disingkat authcode). Ini harus kedaluwarsa mirip dengan id_token yang Anda terima dalam aliran implisit, untuk alasan yang sama dan tidak dapat dan tidak boleh diperbarui.

UI atau aplikasi Anda kemudian memanggil titik akhir Token OP, dan menerima (terkadang setelah pengguna mendapat persetujuan lebih lanjut melalui UI untuk mengizinkan penggunaan sumber daya yang mereka miliki di server OP) keduanya:

• Sebuah id_token, untuk otentikasi - yang tidak boleh digunakan lagi dalam panggilan server, kecuali sebagai petunjuk selama logout, ketika kedaluwarsa tidak penting lagi, dan karenanya, untuk alasan di atas harus dibiarkan kedaluwarsa, dan tidak pernah disegarkan.
• Access_token - yang nantinya, saat memanggil API, dapat diberikan ke titik akhir UserInfo OP. Tindakan tersebut akan mengembalikan klaim, dan API dapat memberikan otorisasi yang sesuai.

Anda dapat menyegarkan access_token ini, karena ini hanya memberi tahu API klaim apa yang dimiliki pengguna, dan sumber daya apa (menurut cakupan dan klaim setiap cakupan) yang disetujui pengguna untuk diberikan kepada Anda. Seperti dijelaskan di atas, ini untuk mengizinkan akses bahkan setelah pengguna tidak masuk lagi. Tentu saja Anda tidak ingin mengizinkan id_token untuk disegarkan, karena Anda tidak ingin mengizinkan peniruan identitas tanpa masuk.

Saya ingin memposting jawaban ini sebagai komentar tetapi karena saya belum terlalu aktif di StackOverflow, saya rasa saya mempostingnya sebagai jawaban alternatif.

Anda juga menggunakan id_tokensebagai id_token_hintsaat mencoba untuk mengeluarkan pengguna dari sesi http://openid.net/specs/openid-connect-session-1_0.html . Sejujurnya saya tidak berpikir bahwa itu sangat penting jika id_tokensudah kedaluwarsa pada saat ini karena Anda hanya khawatir tentang keluar dari pengguna tertentu.

TLDR;

Validasi token ID sebelum memercayai isinya.

Keterangan lebih lanjut

Apa maksud dari waktu kedaluwarsa token ID di OpenID Connect?

Maksudnya adalah untuk memungkinkan klien memvalidasi token ID, dan klien harus memvalidasi token ID sebelum operasi yang menggunakan informasi token ID .

Dari spesifikasi Arus Implisit OpenID :

Jika salah satu prosedur validasi yang ditetapkan dalam dokumen ini gagal, operasi apa pun yang memerlukan informasi yang gagal divalidasi dengan benar HARUS dibatalkan dan informasi yang gagal divalidasi TIDAK HARUS digunakan.

Untuk menguatkan itu, dokumentasi OpenID Connect Google mengatakan ini tentang validasi token ID:

Satu hal yang membuat token ID berguna adalah fakta bahwa Anda dapat meneruskannya ke berbagai komponen aplikasi Anda. Komponen ini dapat menggunakan token ID sebagai mekanisme autentikasi ringan yang mengautentikasi aplikasi dan pengguna. Tetapi sebelum Anda dapat menggunakan informasi dalam token ID atau mengandalkannya sebagai penegasan bahwa pengguna telah mengautentikasi, Anda harus memvalidasinya.

Jadi, jika aplikasi klien kita akan mengambil tindakan berdasarkan konten token ID, maka kita harus memvalidasi token ID lagi.