Prin această postare vreau să deschid o serie de articole dedicate IdentityServer4. Vom începe cu conceptele de bază.
Cel mai promițător protocol de autentificare în acest moment este , iar protocolul de autorizare (acordarea accesului) este . implementarea acestor două protocoale. Este optimizat pentru a rezolva problemele tipice de securitate.
— acesta este un protocol și standard de autentificare, nu oferă acces la resurse (Web API), dar deoarece este dezvoltat deasupra protocolului de autorizare , permite obținerea parametrilor profilului utilizatorului ca și cum ați primit acces la resurse .
(JSON Web Token) reprezintă un standard web care definește modul de transmitere a datelor despre utilizator într-un format JSON într-o formă criptată.
— acesta este un protocol și standard de autorizare. Permite aplicațiilor să obțină acces la resurse protejate, cum ar fi Web API.
Să ne uităm la diagrama de acces la o resursă protejată și să analizăm pașii principali și terminologia acceptată:
Clientul solicită utilizatorului permisiunea de a trece la autentificare în numele său. Clientului — aceasta este aplicația client care solicită acces la resursele protejate în numele proprietarului resurselor. Resursă — acestea sunt toate serviciile noastre protejate .
Utilizatorul permite aplicației client să treacă la autentificare în numele său, de exemplu, introducând un nume de utilizator și o parolă. Numele de utilizator și parola vor constitui un grant de autorizare pentru aplicația client. Utilizator (proprietarul resursei) — este un program sau o persoană care poate oferi acces la resursele protejate, de exemplu, prin introducerea numelui de utilizator (username) și a parolei (password);
Aplicația client solicită un token de acces la
IdentityServer4prin furnizarea de informații despre sine (client_id,client_secret), acordând permisiunea de autorizare din partea utilizatorului (username,parola) și furnizândgrant_typeșiscope. Apoi, serverul de autorizare verifică autenticitatea clientului și datele proprietarului resursei (numele de utilizator și parola).Protocolul OAuth 2.0 efectuează autentificarea nu doar a utilizatorului, ci și a aplicației client care accesează resursele. În acest scop, protocolul prevede parametrii precum client_id și client_secret.
client_id — acesta este identificatorul aplicației client, folositIdentityServer4pentru a căuta informații despre client.
client_secret este echivalentul parolei pentru aplicația client și este utilizat pentru autentificarea aplicației client peIdentityServer4. Secretul clientului trebuie să fie cunoscut doar aplicației și API-ului. Având în vedere cele de mai sus, concluzionăm că IdentityServer4 trebuie să fie conștient de clienții săi.Dacă autenticitatea aplicației este confirmată și autorizarea este validă,
IdentiryServer4creeazăaccess-token(token de acces) pentru aplicație și o cheie opțională de actualizare (refresh-token). Procesul de autorizare este finalizat. Dacă cererea este invalidă sau neautorizată, serverul de autorizare returnează un cod cu un mesaj de eroare corespunzător.Aplicația client accesează date de la un Web API protejat, furnizând tokenul de acces pentru autorizare. Dacă codul răspunsului serverului de resurse , sau , atunci tokenul de acces folosit pentru autentificare este invalid sau expirat.
Dacă tokenul este valid,
Web APIoferă date aplicației.
Tipuri de tokenuri
Clienților înregistrați le este permis să solicite IdentityServer4 -token, IdentityServer4 identityaccess -token șirefresh -token.identity-token (token de identitate)
- — rezultatul procesului de autentificare. Conține identificatorul utilizatorului și informații despre cum și când utilizatorul se autentifică. Poate fi extins cu datele proprii. access-token (token de acces)
- — se transmite către API-ul protejat și este utilizat de acesta pentru autorizarea (permisiunea de acces) la datele sale. refresh-token (token de actualizare)
- — un parametru opțional, pe care serverul de autorizare îl poate returna ca răspuns la cererea de token de acces. Să introducem două concepte suplimentare:
Authenticatation Server Url
— punctul final pentru obținerea cheii de acces. Toate cererile pentru furnizarea și reînnoirea cheilor de acces vor fi direcționate către această adresă URL. Resource Url
— adresa URL a resursei protejate, la care trebuie să se facă referire pentru a obține accesul, trecând cheia de acces în antetul de autorizare. Cerere de cheie de acces
Pentru a solicita o cheie de acces, clientul face
o cerere către punctul final POST cu următorul antet IdentityServer4 'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json', 'Expect': '100-continue'
și transmitând următorii parametri:'grant_type' : 'password', 'username' : login, 'password' : password, 'scope' : 'scope', 'client_id' : 'client_id', 'client_secret' : '{client_secret}'
a fost discutat mai sus. Vom analiza ceilalți parametri:username, parola, client_id și client_secret были разобраны выше. Разберём остальные параметры:
grant_type — tipul de grant sau tipul de permisiune pentru autorizare. Tipul permisiunii pentru autorizare depinde de metoda de solicitare a autorizării utilizată de aplicație, precum și de tipurile de permisiune acceptate de API. În cazul nostru, acesta va avea valoarea parola, conform specificației OAuth 2.0 corespondentă grantului de acreditive ale proprietarului resursei (autorizare prin utilizarea numelui de utilizator și a parolei).
Protocolul OAuth 2.0 definește următoarele tipuri de granturi care necesită interacțiune obligatorie cu utilizatorii:
- cod de autorizare (authorization code). Este unul dintre cele mai răspândite tipuri de permisiune pentru autorizare, deoarece se potrivește bine aplicațiilor server-side, unde codul sursă al aplicației și secretul clientului nu sunt accesibile terților;
- implicit (implicit). Tipul implicit de permisiune pentru autorizare este utilizat de aplicațiile mobile și web, unde confidențialitatea secretului clientului nu poate fi garantată;
Și tipurile de granturi care pot fi efectuate fără interacțiune interactivă cu utilizatorii:
- acreditivul proprietarului resursei (resource owner). Acest tip de permisiune ar trebui utilizat doar în cazul în care aplicația client are încrederea utilizatorului și utilizatorul este confortabil să își introducă numele de utilizator și parola. Acest tip de permisiune ar trebui utilizat doar atunci când alte opțiuni nu sunt disponibile. Acest tip de permisiune este convenabil pentru clienții corporate care, în cadrul sistemului lor, au folosit deja acreditivele utilizatorului și doresc să treacă la
OAuth 2.0. - acreditivele clientului. Sunt utilizate atunci când aplicația accesează API-ul. Aceasta poate fi utilă, de exemplu, atunci când aplicația dorește să își actualizeze informațiile de înregistrare pe serviciu sau URI-ul de redirecționare, sau să acceseze alte informații stocate în contul aplicației pe serviciu, prin intermediul API-ului serviciului.
scope — este un parametru opțional. Acesta definește domeniul de vizibilitate. Tokenul de acces returnat de server va oferi acces doar la serviciile care fac parte din acest domeniu. Adică, putem combina mai multe servicii sub un singur scope și, dacă clientul primește o cheie de acces pentru acest scope, el primește acces la toate aceste servicii. De asemenea, scope-ul poate fi folosit pentru a restricționa drepturile de autorizare (de exemplu, acces la citire sau scriere)
Sursa: habr.com
