Cu această postare vreau să deschid un thread de articole dedicate IdentityServer4. Să începem cu conceptele de bază.
Cel mai promițător protocol de autentificare în acest moment este , iar protocolul de autorizare (care oferă acces) este . implementează aceste două protocoale. Este optimizat pentru rezolvare probleme tipice Securitate.
este un protocol și standard de autentificare, nu oferă acces la resurse (Web API), dar din moment ce este proiectat pe deasupra protocolului de autorizare , vă permite să obțineți parametrii profilului utilizatorului ca și cum ați avea acces la resursă .
(JSON Web Token) este un standard web care definește o modalitate de a transmite datele utilizatorului în format JSON într-o formă criptată.
este un protocol de autorizare și standard. Permite aplicațiilor să acceseze resurse protejate, cum ar fi API-urile Web.
Să aruncăm o privire asupra diagramei de accesare a unei resurse protejate și să înțelegem pașii principali și terminologia acceptată:
-
Clientul solicită permisiunea utilizatorului de a se autentifica în numele său. client este o aplicație client care accesează resurse protejate în numele proprietarului resursei. resursă - acestea sunt toate serviciile noastre protejate .
-
Utilizatorul permite aplicației client să se autentifice în numele său, de exemplu, introducând un nume de utilizator și o parolă. Login-ul și parola vor fi o autorizare pentru aplicația client. Utilizator (proprietarul resursei) — un program sau o persoană care poate acorda acces la resurse protejate, de exemplu, introducând un nume de utilizator (nume de utilizator) și o parolă (parolă);
-
Aplicația client solicită un token de acces de la
IdentityServer4oferind informații despre tine (client_id,client_secret), acordând permisiunea de autorizare din partea utilizatorului (username,password) și oferindgrant_typeиscope. Apoi serverul de autorizare verifică autenticitatea clientului și detaliile proprietarului resursei (login și parolă).Protocolul OAuth 2.0 autentifică nu numai utilizatorul, ci și resursele care accesează aplicația client. În acest scop, protocolul oferă parametri cum ar fi client_id и client_secret.
client_id este identificatorul aplicației client utilizatIdentityServer4pentru a căuta informații despre client.
client_secret este analogă cu o parolă pentru o aplicație client și este folosită pentru a autentifica aplicația clientIdentityServer4. Secretul clientului ar trebui să fie cunoscut doar de aplicație și de API. Pe baza celor de mai sus, tragem concluzia că IdentityServer4 trebuie să știe despre clienții săi. -
Dacă aplicația este autentificată și permisiunea de autorizare este valabilă,
IdentiryServer4creeazăaccess-токен(jeton de acces) pentru aplicație și o cheie de reîmprospătare opțională (refresh-токен). Procesul de autorizare este finalizat. Dacă cererea este nevalidă sau neautorizată, serverul de autorizare returnează un cod cu un mesaj de eroare corespunzător. -
Aplicația client accesează un API Web securizat pentru date, oferind un token de acces pentru autorizare. Dacă codul de răspuns al serverului de resurse , sau , atunci jetonul de acces utilizat pentru autentificare este invalid sau a expirat.
-
Dacă simbolul este valid,
Web APIfurnizează date aplicației.
Tipuri de jetoane
Înregistrat în IdentityServer4 clienții au voie să solicite IdentityServer4 identity-jeton, access-jeton și refresh-jeton.
- jeton de identitate (jeton de identificare) — rezultatul procesului de autentificare. Conține ID-ul utilizatorului și informații despre cum și când utilizatorul este autentificat. Îl puteți extinde cu propriile date.
- jeton de acces — este transmisă unui API protejat și este folosit de acesta pentru a autoriza (permite accesul) la datele sale.
- refresh-token (jeton de reîmprospătare) este un parametru opțional pe care serverul de autorizare îl poate returna ca răspuns la o solicitare de token de acces.
Să introducem încă două concepte:
Url server de autentificare — punct final pentru obținerea unei chei de acces. Vom direcționa toate cererile de furnizare și reînnoire a cheilor de acces către această adresă URL.
Adresa URL a resursei — URL-ul resursei protejate care trebuie contactată pentru a avea acces la ea, trecându-i cheia de acces în antetul de autorizare.
Solicitare cheie de acces
Pentru a solicita o cheie de acces, clientul o face POST cerere către punctul final IdentityServer4 cu următorul titlu
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'și trecerea următorilor parametri:
'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'username, password, client_id и client_secret au fost discutate mai sus. Să ne uităm la parametrii rămași:
tip_grant — tipul grantului sau tipul autorizației. Tipul de permisiune de autorizare depinde de metoda de solicitare de autorizare utilizată de aplicație, precum și de tipurile de permisiuni acceptate de API. În cazul nostru va conta password, care este conform caietului de sarcini OAuth 2.0 corespunde acordării detaliilor de acces ale proprietarului resursei (autorizare prin autentificare și parolă).
protocol OAuth 2.0 definește următoarele tipuri de granturi care necesită interacțiunea obligatorie cu utilizatorii:
- Cod de autorizare. Este unul dintre cele mai comune tipuri de permisiuni de autorizare, deoarece potrivite pentru aplicațiile de pe partea serverului, unde codul sursă al aplicației și secretul clientului nu sunt accesibile persoanelor din afară;
- implicit. Tipul de autorizare implicită este utilizat de aplicațiile mobile și web unde confidențialitatea secretului clientului nu poate fi garantată;
Și tipurile de granturi care poate fi executat fără interacțiunea utilizatorului:
- detaliile proprietarului resursei. Acest tip de permisiune ar trebui utilizat numai dacă aplicația client este de încredere de către utilizator și utilizatorul este confortabil să introducă numele și parola. Acest tip de permisiune ar trebui utilizat numai atunci când nu sunt disponibile alte opțiuni. Acest tip de permisiune este convenabil pentru clienții corporativi care au folosit deja acreditările de utilizator în sistemul lor și doresc să comute
OAuth 2.0. - acreditările clientului. Folosit atunci când aplicația accesează API-ul. Acest lucru poate fi util, de exemplu, atunci când o aplicație dorește să-și actualizeze propriile informații de înregistrare a serviciului sau să redirecționeze URI sau să acceseze alte informații stocate în contul de serviciu al aplicației prin intermediul API-ului serviciului.
domeniu - Acesta este un parametru opțional. Acesta definește domeniul de aplicare. Indicatorul de acces returnat de server va oferi acces numai la serviciile care se încadrează în acel domeniu. Acestea. putem combina mai multe servicii într-un singur domeniu și dacă clientul primește o cheie de acces la acest domeniu, el are acces la toate aceste servicii. Domeniul de aplicare poate fi folosit și pentru a limita drepturile de autorizare (de exemplu, acces de citire sau scriere)
Sursa: www.habr.com
