🥇IdentityServer4. Konsep asas. OpenID Connect, OAuth 2.0 dan JWT

Dengan siaran ini saya ingin membuka rangkaian artikel khusus untuk IdentityServer4. Mari kita mulakan dengan konsep asas.

Protokol pengesahan yang paling menjanjikan pada masa ini ialah OpenID Connect, dan protokol kebenaran (menyediakan akses) ialah OAuth 2.0. IdentityServer4 melaksanakan kedua-dua protokol ini. Ia dioptimumkan untuk diselesaikan masalah tipikal keselamatan.

OpenID Connect ialah protokol dan standard pengesahan, ia tidak menyediakan akses kepada sumber (API Web), tetapi sejak ia direka bentuk di atas protokol kebenaran OAuth 2.0, ia membolehkan anda mendapatkan parameter profil pengguna seolah-olah anda mempunyai akses kepada sumber tersebut Maklumat Pengguna.
J.W.T. (JSON Web Token) ialah standard web yang mentakrifkan cara untuk menghantar data pengguna dalam format JSON dalam bentuk yang disulitkan.
OAuth 2.0 (RFC 6749) ialah protokol dan standard kebenaran. Ia membenarkan aplikasi mengakses sumber yang dilindungi, seperti API Web.

Mari kita lihat gambar rajah mengakses sumber yang dilindungi dan fahami langkah utama serta istilah yang diterima:

Pelanggan meminta kebenaran daripada pengguna untuk mengesahkan bagi pihaknya. Pelanggan ialah aplikasi klien yang mengakses sumber yang dilindungi bagi pihak pemilik sumber. sumber - ini semua adalah perkhidmatan kami yang dilindungi API Web.
Pengguna membenarkan aplikasi klien untuk mengesahkan bagi pihaknya, contohnya, dengan memasukkan log masuk dan kata laluan. Log masuk dan kata laluan akan menjadi pemberian kebenaran untuk aplikasi klien. Pengguna (pemilik sumber) — program atau orang yang boleh memberikan akses kepada sumber yang dilindungi, contohnya, dengan memasukkan log masuk (nama pengguna) dan kata laluan (kata laluan);
Aplikasi klien meminta token akses daripada IdentityServer4 dengan memberikan maklumat tentang diri anda (client_id, client_secret), memberikan kebenaran kebenaran daripada pengguna (username, password) dan menyediakan grant_type и scope. Kemudian pelayan kebenaran mengesahkan ketulenan klien dan butiran pemilik sumber (log masuk dan kata laluan).
Protokol OAuth 2.0 mengesahkan bukan sahaja pengguna, tetapi juga aplikasi klien yang mengakses sumber. Untuk tujuan ini, protokol menyediakan parameter seperti pelanggan_id и pelanggan_secret.
id_pelanggan ialah pengecam aplikasi klien yang digunakan IdentityServer4 untuk mencari maklumat tentang klien.
pelanggan_secret adalah serupa dengan kata laluan untuk aplikasi klien dan digunakan untuk mengesahkan aplikasi klien pada IdentityServer4. Rahsia pelanggan hanya perlu diketahui oleh aplikasi dan API. Berdasarkan perkara di atas, kami membuat kesimpulan bahawa IdentityServer4 perlu tahu tentang pelanggannya.
Jika permohonan disahkan dan kebenaran kebenaran adalah sah, IdentiryServer4 mencipta access-токен (token akses) untuk aplikasi dan kunci muat semula pilihan (refresh-токен). Proses kebenaran selesai. Jika permintaan itu tidak sah atau tidak dibenarkan, pelayan kebenaran mengembalikan kod dengan mesej ralat yang sesuai.
Aplikasi klien mengakses API Web selamat untuk data, menyediakan token akses untuk kebenaran. Jika kod tindak balas pelayan sumber 401, 403 atau 498, maka token akses yang digunakan untuk pengesahan adalah tidak sah atau tamat tempoh.
Jika token itu sah, Web API menyediakan data kepada aplikasi.

Jenis token

Berdaftar di IdentityServer4 pelanggan dibenarkan untuk meminta IdentityServer4 identity-token, access-token dan refresh-token.

token identiti (token pengenalan) — hasil daripada proses pengesahan. Mengandungi ID pengguna dan maklumat tentang cara dan bila pengguna disahkan. Anda boleh mengembangkannya dengan data anda sendiri.
token akses — dihantar ke API yang dilindungi dan digunakan olehnya untuk membenarkan (membenarkan akses) kepada datanya.
refresh-token (token segar semula) ialah parameter pilihan yang boleh dikembalikan oleh pelayan kebenaran sebagai tindak balas kepada permintaan token akses.

Mari perkenalkan dua lagi konsep:

Url Pelayan Pengesahan — titik akhir untuk mendapatkan kunci akses. Kami akan mengarahkan semua permintaan untuk penyediaan dan pembaharuan kunci akses ke URL ini.

Url Sumber — URL sumber dilindungi yang mesti dihubungi untuk mendapatkan akses kepadanya, memberikannya kunci akses dalam pengepala kebenaran.

Permintaan kunci akses

Untuk meminta kunci akses, pelanggan melakukannya POST permintaan untuk titik akhir IdentityServer4 dengan tajuk berikut

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

dan lulus parameter berikut:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret telah dibincangkan di atas. Mari lihat parameter yang tinggal:

hibah_jenis — jenis pemberian atau jenis kebenaran. Jenis kebenaran kebenaran bergantung pada kaedah permintaan kebenaran yang digunakan oleh aplikasi, serta jenis kebenaran yang disokong oleh API. Dalam kes kami, ia akan menjadi penting password, yang mengikut spesifikasi OAuth 2.0 sepadan dengan pemberian butiran akses pemilik sumber (kebenaran melalui log masuk dan kata laluan).

Protokol OAuth 2.0 mentakrifkan jenis geran berikut yang memerlukan interaksi wajib dengan pengguna:

kod kebenaran. Ia adalah salah satu jenis kebenaran kebenaran yang paling biasa, kerana sangat sesuai untuk aplikasi bahagian pelayan, di mana kod sumber aplikasi dan rahsia pelanggan tidak boleh diakses oleh orang luar;
tersirat. Jenis kebenaran kebenaran tersirat digunakan oleh aplikasi mudah alih dan web di mana kerahsiaan rahsia pelanggan tidak dapat dijamin;

Dan jenis-jenis geran yang boleh dilaksanakan tanpa interaksi pengguna:

butiran pemilik sumber. Jenis kebenaran ini harus digunakan hanya jika aplikasi klien dipercayai oleh pengguna dan pengguna selesa dengan memasukkan log masuk dan kata laluannya. Jenis kebenaran ini hanya boleh digunakan apabila tiada pilihan lain tersedia. Jenis kebenaran ini sesuai untuk pelanggan korporat yang telah menggunakan kelayakan pengguna dalam sistem mereka dan ingin bertukar kepada OAuth 2.0.
kelayakan pelanggan. Digunakan apabila aplikasi mengakses API. Ini boleh berguna, contohnya, apabila aplikasi ingin mengemas kini maklumat pendaftaran perkhidmatannya sendiri atau mengubah hala URI, atau mengakses maklumat lain yang disimpan dalam akaun perkhidmatan aplikasi melalui API perkhidmatan.

skop - Ini adalah parameter pilihan. Ia mentakrifkan skop. Token akses yang dikembalikan oleh pelayan hanya akan menyediakan akses kepada perkhidmatan yang termasuk dalam skop tersebut. Itu. kami boleh menggabungkan beberapa perkhidmatan di bawah satu skop dan jika pelanggan menerima kunci akses kepada skop ini, dia mendapat akses kepada semua perkhidmatan ini. Skop juga boleh digunakan untuk mengehadkan hak kebenaran (contohnya, akses baca atau tulis)

Sumber: www.habr.com