IdentityServer4. Põhimõisted. OpenID Connect, OAuth 2.0 ja JWT

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

Praegu on kõige lootustandvam autentimise protokoll OpenID Connect, samas kui volituste (juurdepääsu) protokoll on OAuth 2.0. IdentityServer4 rakendab neid kahte protokolli. See on optimeeritud lahendama tüüpilisi probleeme turvalisuse.

OpenID Connect — see on autentimise protokoll ja standard, mis ei anna juurdepääsu ressurssidele (Web API), kuid kuna see on välja töötatud volituste protokolli peale, OAuth 2.0kuid see võimaldab saada kasutaja profiiliväärtusi just nagu oleksite saanud juurdepääsu ressurssidele UserInfo.

JWT (JSON Web Token) on veebistandard, mis määratleb viisi, kuidas edastada kasutajaandmeid JSON-formaadis krüpteeritud kujul.

OAuth 2.0 (RFC 6749) — see on volituste protokoll ja standard. See võimaldab rakendustel pääseda ligi kaitstud ressurssidele, näiteks Web API-le.

Vaadakem diagrammi kaitstud ressursi juurde pääsemisest ja uurime põhietappe ja kasutatavat terminoloogiat:

1. Kliendi nõuab kasutajalt luba autoriseerimiseks tema nimel. Klient — on kliendi rakendus, mis pöördub turvalistele ressurssidele nende omaniku nimel. Ressurss — need on kõik meie kaitstud teenused Web API.

2. Kasutaja lubab kliendi rakendusel autoriseerida end tema nimel, näiteks sisestades kasutajanime ja parooli. Need, kasutajanimi ja parool, toimivad kliendi rakenduse autoriseerimise volitusena. Kasutaja (ressursi omanik) — programm või inimene, kes saab anda juurdepääsu kaitstud ressurssidele, näiteks kasutajanime (username) ja parooli (password) sisestamise kaudu;

3. Kliendi rakendus küsib juurdepääsutükki IdentityServer4 enne, kui esitavad teavet enda kohta (client_id, client_secret), andes kasutaja autoriseerimiseks loa (username, password) ning esitades grant_type ja scope. Seejärel kontrollib autoriseerimiserver kliendi ja ressursi omaniku (kasutajanime ja parooli) autentimise.

   OAuth 2.0 protokoll autentib mitte ainult kasutajat, vaid ka kliendi rakendust, mis pääseb ressurssidele juurde. Selleks sisaldab protokoll selliseid parameetreid nagu client_id ja client_secret.
   client_id — see on kliendi rakenduse identifikaator, mida kasutatakse IdentityServer4 kliendi teabe otsimiseks.
   client_secret on simuleerib kliendi rakenduse parooli ja seda kasutatakse kliendi rakenduse autentimiseks IdentityServer4. Kliendi saladus peaks olema tuntud ainult rakendusele ja API-le. Seega järeldame, et IdentityServer4 peab teadma oma kliente.

4. Kui rakenduse autentsus on kinnitatud ja autoriseerimise luba on kehtiv, IdentityServer4 loomise access-tokeni (juurdepääsutoken) rakenduse jaoks ja valikulise värskenduse võtme (refresh-token). Autoriseerimisprotsess on lõpetatud. Kui päring on ebaõiglane või volitamata, tagastab autoriseerimisteenuse server vastava veakoodi.

5. Kliendi rakendus võtab kaitstud veeb API-lt andmeid, esitades samal ajal juurdepääsutokeni autoriseerimiseks. Kui serveri ressursi vastuse kood 401, 403 või 498, siis on autentimiseks kasutatav juurdepääsutoken kehtetu või aegunud.

6. Kui token on kehtiv, Web API edastab andmed rakendusele.

Tokeni tüübid

registreeritud IdentityServer4 klientidele on lubatud küsida IdentityServer4 identity-token, access-token ja refresh-token.

• identity-token (tuvastustoken) — autentimise protsessi tulemus. Sisaldab kasutaja tuvastajat ja teavet selle kohta, kuidas ja millal kasutaja autentimist sooritab. Saate seda oma andmetega laiendada.
• access-token (juurdepääsutoken) — edastatakse kaitstud API-le ning seda kasutatakse autoriseerimiseks (juurdepääsu lubamiseks) oma andmetele.
• refresh-token (uuendustoken) — valikuline parameeter, mille autoriseerimiserver võib tagasi saata juurdepääsutokeni päringu vastusena.

Lisame veel kaks mõistet:

Authenticattion Server Url — lõpp-punkt juurdepääsuvõtme saamiseks. Kõik päringud juurdepääsuvõtmete andmiseks ja taaskäivitamiseks suunatakse sellele URL-ile.

Resource Url — kaitstud ressursi URL, millele tuleb pöörduda, et sellele juurde pääseda, edastades sellele juurdepääsuvõtme autoriseerimise päises.

Juurdepääsuvõtme pärimine

Juurdepää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, password, client_id ja client_secret olidud on juba analüüsitud. Vaatame üle ülejäänud parameetrid:

grant_type — grant tüüpi või volituse tüüpi. Volituse tüüp sõltub rakenduses kasutatavast volituste päringust ja milliseid volituse tüüpe API toetab. Meie juhul on see password, mis vastab spetsifikatsioonile OAuth 2.0 tööst, mis vastab ressurssi omaniku juurdepääsu volituskohtadele (autentimine kasutajanime ja parooli abil).

Protokoll OAuth 2.0 määratleb järgmised volitused, mis nõuavad kohustuslikku kasutajate interaktsiooni:

• autentimiskood (authorization code). See on üks levinumaid volituse tüüpe, kuna see sobib hästi serveripoolsetele rakendustele (server-side applications), kus rakenduse lähtekood ja kliendi saladus ei ole kolmandate isikute jaoks ligipääsetavad;
• kaudne (implicit). Kaudset autentimise volitust kasutatakse mobiil- ja veebirakendustes, kus kliendi saladuse konfidentsiaalsust ei saa tagada;

Ja volituse tüübid, mis võivad toimida ilma kohustuslikku kasutajate interaktsioonita:

• ressursi omaniku andmed. Seda tüüpi volitusi tuleks kasutada ainult siis, kui kliendi rakendus naudib kasutaja usaldust ja kasutaja on rahul oma kasutajanime ja parooli sisestamisega. Seda tüüpi volitusi tuleks kasutada ainult siis, kui teised valikud pole saadaval. See tüüp volitusi on mugav ettevõtte klientidele, kes on oma süsteemis juba kasutanud kasutaja volitusi ja soovivad üle minna OAuth 2.0.
• kliendi volitustele. Neid 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 suunamiste URI-d, või juurdepääsuks muudele andmetele, mis on rakenduse kontol teenuses, teenuse API kaudu.

scope — see on valikuline parameeter. See määrab ulatuse. Serveri tagastatud juurdepääsu token võimaldab juurdepääsu ainult neile teenustele, mis kuuluvad sellesse ulatusse. St. me saame mitu teenust kokku koondada ühe ulatuse alla ja kui klient saab juurdepääsu võtme sellele ulatusele, saab ta juurdepääsu kõigile neile teenustele. Ulatust saab kasutada ka autoriseerimisõiguste piiramiseks (näiteks lugemis- või kirjutamisõigused).

Allikas: habr.com