Apa maksud dari waktu kadaluwarsa Token ID di OpenID Connect?

93

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).

oauth-2.0  openid-connect 
— Appetere
sumber

Jawaban:

91

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.
— Appetere
sumber
3
Apakah Anda punya referensi untuk ini? Eugenio mengklaim Anda dapat menyegarkan token id dalam jawabannya. Apakah ini benar?
— AndyD
6
Anda tidak dapat menyegarkan token ID, dalam arti memperpanjang kadaluwarsanya (dengan cara token akses dapat disegarkan dengan menggunakan token akses offline). Tetapi jika Anda memiliki sesi otentikasi yang belum kedaluwarsa dengan OpenID Connect Provider (misalnya cookie setelah masuk ke IdentityServer3) maka ketika Anda mengulangi permintaan login, Penyedia dapat melewati otentikasi (karena cookie mengatakan Anda telah melakukannya) dan hanya mengembalikan a Token ID baru (& akses-token jika diminta). Ini hanya berfungsi jika cookie memiliki masa pakai lebih lama daripada ID Token, tentunya.
— Appetere
1
Meskipun Anda dapat melakukan ini, saya tidak yakin apakah benar melakukannya. Ini juga tidak akan mulus bagi pengguna akhir, karena akan membutuhkan beberapa pengalihan browser.
— Kir
@Kir Jika Anda menggunakan aplikasi halaman tunggal Javascript (SPA), maka upaya pertama pada pembaruan acces-token biasanya akan menjadi proses latar belakang, sehingga pengguna akhir tidak akan terganggu. Misalnya, jika API sumber daya Anda merespons bahwa token akses telah kedaluwarsa, SPA membuat permintaan latar belakang ke Server Identitas untuk mendapatkan token akses baru. Hanya jika ini gagal (karena token ID telah kedaluwarsa) Anda harus meminta pengguna untuk login lagi. Lihat contoh JavascriptImplicitClient di github.com/IdentityServer/IdentityServer3.Samples/tree/master/… untuk contoh kode.
— Appetere
Anda dapat menyegarkan Id_token, jika penyedia OIdC mendukung mengembalikannya dari permintaan Refresh_token. Lihat stackoverflow.com/questions/41168304/… dan stackoverflow.com/questions/41741982/…
— Michael Freidgeim
37

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.

— Scott Willeke
sumber
Jika Anda menulis perangkat lunak umum untuk bekerja dengan penyedia Otorisasi arbitrer, Anda tidak dapat mengandalkan mengembalikan id_token dari penyegaran. Namun jika Anda bekerja dengan penyedia tertentu (seperti IdentityServer4), Anda dapat memeriksa kemampuannya, dan menggunakan id_token yang diterima setelah permintaan penyegaran
— Michael Freidgeim
Jadi bagaimana id_token bisa disegarkan?
— jwilleke
@jwilleke AFAIK, seperti yang dikatakan di atas "satu-satunya cara untuk mendapatkan Token ID baru adalah dengan mengotorisasi ulang / mengautentikasi pengguna dengan mengarahkan pengguna ke titik akhir otorisasi"
— Scott Willeke
@MichaelFreidgeim Menarik, maksud Anda melalui mekanisme Open ID Connect Discovery ? Bagaimana tepatnya kita melakukannya?
— Scott Willeke
1
Jawaban bagus pada "isi respons penyegaran mungkin tidak berisi id_token". Suara positif. Omong-omong, pemahaman saya adalah spesifikasi OIDC tidak memberikan kelonggaran untuk menggunakan Refresh Token untuk mendapatkan token ID baru: klien dapat melakukannya dengan menentukan "id_token" sebagai salah satu cakupan; tetapi kehati-hatian umum masih berlaku di sini, karena Server Otentikasilah yang membuat keputusan akhir tentang apakah akan mematuhi cakupan yang Anda minta.
— RayLuo
7

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).

— Morrowless
sumber
6

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.

— Eugenio Pace
sumber
Terima kasih Eugenio. Pertanyaan utama yang saya miliki adalah apa yang harus Anda lakukan ketika token ID kedaluwarsa? Saya berpikir (mungkin salah) bahwa untuk memperbarui token akses berumur pendek Anda HARUS menggunakan token penyegaran. Tetapi jika ID-token memiliki masa kadaluwarsa yang sama dengan token akses, Anda akan segera memiliki ID-token yang kedaluwarsa, jadi sepertinya tidak ada gunanya menyegarkan token akses. Pikir saya mungkin melewatkan sesuatu di sini!
— Appetere
1
Anda akan menggunakan refresh_token (tidak dicabut) untuk mendapatkan access_token atau id_token baru. Atau cukup sebagai pengguna untuk login kembali. id_tokens secara logis setara dengan access_tokens. Hanya format yang berbeda.
— Eugenio Pace
2
Pemahaman terbaru saya adalah bahwa ketika pengguna memiliki sesi yang diautentikasi dengan server otorisasi, ketika token akses kedaluwarsa, 401 => 302 pengalihan ke server otorisasi akan mendapatkan akses baru & token ID tanpa campur tangan pengguna. Tetapi dalam mode offline, refresh_token hanya akan mengembalikan access_token baru yang mengatakan pengguna tertentu diizinkan untuk mengakses beberapa sumber daya. Itu tidak dapat mengembalikan id_token, karena itu akan mengatakan bahwa pengguna tertentu diautentikasi dan dalam mode offline itu tidak terjadi.
— Appetere
Ini akan menjadi jawaban yang bagus untuk pertanyaan tentang apa perbedaan antara id_token dan access_token (terutama saat menggunakan token opaque / referensi). Fokus pada menjawab pertanyaan terlebih dahulu dan kemudian klarifikasi bagaimana token akses dan token id digunakan?
— Trent
5

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.

— pashute
sumber
2
Apa yang Anda katakan tentang aliran implisit sebagian tidak benar. Klien yang menggunakan aliran implisit dapat memperoleh token akses selain token ID dan dapat menggunakan token akses tersebut untuk berinteraksi dengan server.
— Shaun Luttin
Ada praktik umum, bahwa ketika id_token habis masa berlakunya, klien meminta token baru dari server, sehingga pengguna tidak perlu memberi otorisasi lagi. Misalnya lihat damienbod.com/2017/06/02/…
— Michael Freidgeim
4

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.

— dgonee
sumber
4

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.

— Shaun Luttin
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.