IdentityServer4. Peamised mõisted. OpenID Connect, OAuth 2.0 ja JWT

Selle postitusega soovin alustada artiklite seeriat, mis on pühendatud IdentityServer4-le. Alustame peamistest mõistetest.

Praegu on kõige perspektiivikam autentimisprotokoll OpenID Connect, autoriseerimise (juurdepääsu andmise) protokoll on OAuth 2.0. IdentityServer4 , mis toetab neid kaht protokolli. See on optimeeritud tüüpiliste probleemide lahendamiseks turvalisuse. — see on autentimisprotokoll ja standard, mis ei anna juurdepääsu ressurssidele (Web API), kuid kuna see on välja töötatud autoriseerimisprotokolli pinnal

OpenID Connect , võimaldab see saada kasutaja profiili parameetreid, justkui oleksite saanud juurdepääsu ressursile OAuth 2.0UserInfo (JSON Web Token) on veebistandard, mis määratleb viisi kasutajaandmete edastamiseks JSON-formaadis krüpteeritud kujul..

JWT OAuth 2.0 (RFC 6749)

— see on autoriseerimisprotokoll ja standard. See võimaldab rakendustel pääseda juurde kaitstud ressurssidele, näiteks Web API-le. Vaadakem, kuidas kaitstud ressursse kutsuda, ja selgitage peamisi samme ja aktsepteeritud terminoloogiat:

Kliendi rakendus palub kasutajalt luba autoriseerimise läbiviimiseks tema nimel.

1. — see on kliendirakendus, mis pöördub kaitstud ressursside poole omaniku nimel. Kliendi — need on kõik meie kaitstud teenused Allikas Kasutaja lubab kliendirakendusel autoriseerimise läbi viia tema nimel, näiteks sisestades sisselogimise ja parooli. Sisselogimine ja parool on autoriseerimisõiguse andmise tõend kliendirakendusele. Veebi API.

2. Kasutaja (ressursi omanik) — programm või inimene, kes võib anda juurdepääsu kaitstud ressurssidele, näiteks sisselogimise (username) ja parooli (password) sisestamise teel; Kliendirakendus küsib juurdepääsu märki

3. esitamata enda kohta teavet ( IdentityServer4 client_secretclient_id, ), kasutades kasutaja autoriseerimisluba () ja esitadesusername, paroolgrant_type . Seejärel kontrollib autoriseerimiserver kliendi ja ressursi omanikku (sisselogimine ja parool) autentimist. ja scopeOAuth 2.0 protokoll tõendab mitte ainult kasutaja, vaid ka kliendirakenduse, mis pääseb ressurssidele. Selleks on protokollis ette nähtud sellised parameetrid nagu

   client_id client_id ja ), kasutades kasutaja autoriseerimisluba (.
   — see on kliendirakenduse identifikaator, mida kasutatakse kliendi teabe otsimiseks. IdentityServer4 on kliendirakenduse parooli analoog ja seda kasutatakse kliendirakenduse autentimiseks.
   ), kasutades kasutaja autoriseerimisluba ( on kliendi rakenduse sarnane parool, mida kasutatakse kliendi rakenduse autentimiseks IdentityServer4. Kliendi saladus peab olema teada ainult rakendusele ja API-le. Ülaltoodust lähtudes järeldame, et IdentityServer4 peab teadma oma kliente.

4. Kui rakenduse ehtsust on kinnitatud ja autoriseerimise luba on kehtiv, IdentiryServer4 loob access-token'i (ligipääsutoken) rakenduse jaoks ja valikulise värskendustõe (refresh-token). Autoriseerimisprotsess on lõpetatud. Kui päring on kehtetu või volitamata, tagastab autoriseerimiserver vastuse koos vastava veateatega.

5. Kliendirakendus küsib andmeid kaitstud Web API-lt, esitades samas ligipääsutokeni autoriseerimiseks. Kui serveri ressursside vastuskood 401, 403 või 498, siis on autoriseerimiseks kasutatud ligipääsutoken kehtetu või aegunud.

6. Kui token on kehtiv, Veebi API tagastab andmed rakendusele.

Tokenite tüübid

Registritud IdentityServer4 klientidele lubatakse küsida IdentityServer4 identity-tokenit, access-tokenit ja värskenda-tokenit.

• identity-token (identifitseerimistoken) on autentsuse protsessi tulemus. Sisaldab kasutaja identifikaatorit ja teavet selle kohta, kuidas ja millal kasutaja autentimiseks läbib. Saate laiendada oma andmetega.
• access-token (ligipääsutoken) edastatakse kaitstud API-le ja kasutatakse selle poolt autoriseerimiseks (ligipääsu lubamiseks) oma andmetele.
• refresh-token (värskendustoken) on valikuline parameeter, mille autoriseerimiserver võib tagastada vastuseks ligipääsutokeni päringule.

Tutvustame veel kahte mõistet:

Authenticatation Server Url on lõpp-punkt, mille kaudu pääseb juurde ligipääsuvõtmele. Kõik päringud ligipääsuvõtme väljastamiseks ja uuendamiseks saadetakse sellele URL-ile.

Resource Url on kaitstud ressursi URL, millele tuleb pöörduda, et sellele ligi pääseda, edastades selle kaudu ligipääsuvõtme autoriseerimise päises.

Ligipääsuvõtme pärimine

Ligipääsuvõtme pärimiseks teeb klient POST päringu lõpp-punktile IdentityServer4 järgmise päisega

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

ja edastades järgmised parameetrid:

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

username, parool, client_id ja ), kasutades kasutaja autoriseerimisluba ( olid eelnevalt käsitletud. Uurime ülejäänud parameetreid:

. Seejärel kontrollib autoriseerimiserver kliendi ja ressursi omanikku (sisselogimine ja parool) autentimist. — mandaatide või volituste tüüp. Volituse tüüp sõltub rakenduse poolt kasutatavast autoriseerimismeetodist ja sellest, milliseid volitustüüpe API toetab. Meie puhul on see parool, vastavalt spetsifikatsioonile OAuth 2.0 vastab ressursiomaniku juurdepääsuvõimaluste mandaatidele (autoriseerimine kasutajanime ja parooli abil).

Protokoll OAuth 2.0 määratleb järgmised volitustüübid, mis nõuavad kohustuslikku kasutajate kaasamise:

• autoriseerimiskood (authorization code). See on üks levinumaid autoriseerimistüüpe, kuna see sobib hästi serveripoolsete rakenduste jaoks, kus rakenduse lähtekood ja kliendi saladus ei ole kolmandate isikute kätte saadavad;
• kaudne (implicit). Kaudset autoriseerimistüüp on kasutatakse mobiil- ja veebirakendustes, kus kliendi saladuse konfidentsiaalsust ei saa tagada;

Ja volitustüübid, mis võivad toimuda ilma interaktiivse kasutajate kaasamiseta:

• ressursiomaniku andmed (resource owner). Seda autoriseerimistüüpi tuleks kasutada ainult siis, kui kliendirakendus naudib kasutaja usaldust ja kasutaja võib rahulikult oma kasutajanime ja parooli sisestada. Seda autoriseerimistüüpi tuleks kasutada ainult siis, kui teised variandid pole saadaval. See autoriseerimistüüp on mugav ettevõtte klientidele, kes on oma süsteemis juba kasutanud kasutaja mandaatide andmeid ja soovivad minna üle OAuth 2.0.
• kliendi mandaatide. Kasutatakse rakenduse juurdepääsuks API-le. See võib olla kasulik näiteks siis, kui rakendus soovib värskendada oma registreerimise teavet teenuses või URI suunamisteavet, või juurdepääsu muudele teabele, mis on rakenduse kontol teenuses API kaudu talletatud.

scope — see on valikuline parameeter. See määratleb nähtavuse. Serveri tagastatud ligipääsu token annab ligipääsu ainult nendele teenustele, mis kuuluvad sellesse valdkonda. St saame mitu teenust ühendada ühe ulatuse alla ja kui klient saab ligipääsuvõtme sellele ulatusele, saadakse ligipääs kõigile nendele teenustele. Samuti võib ulatus olla kasutatud autoriseerimisõiguste piiramiseks (näiteks lugemis- või kirjutamisõigus)

Allikas: habr.com