IdentityServer4. Konceptet kryesore. OpenID Connect, OAuth 2.0 dhe JWT

Me këtë post dëshiroj të hap një seri artikujsh consacratuar IdentityServer4. Të fillojmë nga konceptet kryesore.

Protokolli më premtues në këtë moment për autentifikim është OpenID Connect, dhe protokolli për autorizim (dhënie aksesit) është OAuth 2.0. IdentityServer4 implementon këto dy protokolle. Ai është optimizuar për të zgjidhur problemet tipike të sigurisë.

OpenID Connect — ky është një protokoll dhe standard autentifikimi, ai nuk jep akses në burime (Web API), por pasi është zhvilluar mbi protokollin e autorizimit OAuth 2.0, ai lejon marrjen e parametrave të profilit të përdoruesit siç do të kishit marrë akses në burimin UserInfo.

JWT (JSON Web Token) paraqet një standard web-i që përcakton mënyrën e transferimit të të dhënave mbi përdoruesin në formatin JSON në një formë të enkriptuar.

OAuth 2.0 (RFC 6749) — ky është një protokoll dhe standard autorizimi. Ai lejon aplikacioneve të kenë akses në burime të mbrojtura, si p.sh. Web API.

Le të shohim diagramin e kërkesës për burime të mbrojtura dhe të zbërthejmë hapat kryesorë dhe terminologjinë e pranuar:

1. Klienti kërkon nga përdoruesi leje për të kaluar autorizimin në emrin e tij. Klienti — është një aplikacion klienti që qasje në burimet e mbrojtura në emër të pronarit të burimeve. Burimi — janë të gjitha shërbimet tona të mbrojtura Web API.

2. Përdoruesi lejon aplikacionin klient të autorizohet në emrin e tij, për shembull, duke futur emrin e përdoruesit dhe fjalëkalimin. Emri i përdoruesit dhe fjalëkalimi do të shërbejnë si grant autorizimi për aplikacionin klient. Përdoruesi (pronari i burimit) — është një program ose person që mund të japë qasje në burime të mbrojtura, për shembull, duke futur emrin e përdoruesit (username) dhe fjalëkalimin (password);

3. Aplikacioni klient kërkon një token qasje nga IdentityServer4 duke ofruar informacion mbi veten (client_id, client_secret), duke ofruar lejen për autorizim nga përdoruesi (username, password) dhe duke ofruar grant_type dhe scope. Pastaj, serveri i autorizimit verifikon autencitetin e klientit dhe të dhënat e pronarit të burimit (emri i përdoruesit dhe fjalëkalimi).

   Protokolli OAuth 2.0 kryen autentikimin jo vetëm të përdoruesit, por edhe të aplikacionit klient që po akseson burimet. Për këtë, protokolli parashikon parametra të tillë si client_id dhe client_secret.
   client_id — është identifikuesi i aplikacionit klient që përdoret IdentityServer4 për të kërkuar informacionin mbi klientin.
   client_secret është një analog i fjalëkalimit për aplikacionin klient dhe përdoret për autentifikimin e aplikacionit klient në IdentityServer4. Sekreti i klientit duhet të jetë i njohur vetëm për aplikacionin dhe API-në. Duke u bazuar në të dhënat e mësipërme, arrihet në përfundimin se IdentityServer4 duhet të dijë për klientët e tij.

4. Nëse autenticiteti i aplikacionit konfirmohet dhe leja për autorizim është e vlefshme, IdentiryServer4 krijon token-in e aksesit (token akses) për aplikacionin dhe një çelës opsional rinovimi (token rinovimi). Procesi i autorizimit është përfunduar. Nëse kërkesa është e pavlefshme ose e paautorizuar, serveri i autorizimit kthen një kod me mesazhin përkatës të gabimit.

5. Aplikacioni klient i drejtohet API-së së sigurt Web për të marrë të dhëna, duke ofruar token-in e aksesit për autorizim. Nëse kodi i përgjigjes nga serveri i burimeve 401, 403 ose 498, atëherë token-i i aksesit i përdorur për autentifikim është i pavlefshëm ose i skaduar.

6. Nëse token-i është i vlefshëm, Web API ofron të dhënat për aplikacionin.

Llojet e tokeneve

Të regjistruarve në IdentityServer4 klientët u lejohet të kërkojnë IdentityServer4 token-in e identitetit-token, access-token dhe rinovim-token.

• token-i i identitetit (token identifikimi) — rezultati i procesit të autentikimit. Përmban identifikuesin e përdoruesit dhe informacion mbi mënyrën dhe kur përdoruesi kalon autentikimin. Mund të zgjerohet me të dhëna të tjera.
• tokeni i aksesit (tokeni i acesso) — transmetohet në API të mbrojtur dhe përdoret prej tij për autorizimin (lejonin qasje) në të dhënat e tij.
• tokeni i rifreskimit (tokeni i rifreskimit) — një parametër joobligator që serveri i autorizimit mund ta kthejë si përgjigje ndaj kërkesës për tokenin e aksesit.

Le të futim gjithashtu dy koncepte të tjera:

URL e Serverit të Autentikimit — pika përfundimtare për marrjen e çelësit të aksesit. Të gjitha kërkesat për ofrimin dhe rinovimin e çelësave të aksesit do të drejtohen në këtë URL.

URL e Burimit — URL e burimit të mbrojtur, në të cilin duhet të adresohemi për të fituar qasje, duke i kaluar çelësin e aksesit në titullin e autorizimit.

Kërkesa për çelësin e aksesit

Për të kërkuar çelësin e aksesit, klienti bën POST kërkesë në pikën përfundimtare IdentityServer4 me titullin e mëposhtëm

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

dhe kalon parametrat e mëposhtëm:

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

username, password, client_id dhe client_secret u diskutuan më parë. Le të shqyrtojmë parametrat e tjerë:

grant_type — lloji i grantit ose lloji i lejes për autorizim. Lloji i lejes për autorizim varet nga metoda e kërkesës për autorizim të përdorur nga aplikacioni, si dhe nga llojet e lejes që mbështeten nga API. Në rastin tonë, ai do të ketë vlerën password, e cila sipas specifikimeve OAuth 2.0 përkon me grantin e akreditiveve të pronarit të burimit (autorizimi me emrin e përdoruesit dhe fjalëkalimin).

Protokolli OAuth 2.0 përcakton llojet e mëposhtme të grantëve që kërkojnë ndërveprim të detyrueshëm me përdoruesit:

• kode autorizimi (authorization code). Ai është një nga llojet më të përhapura të lejes për autorizim, pasi është perfekt për aplikacionet server-side, ku kodi burimor i aplikacionit dhe sekreti i klientit nuk janë të aksesueshëm për të tjerët;
• të fshehtë (implicit). Lloji i fshehtë i lejes për autorizim përdoret nga aplikacionet mobile dhe web, ku konfidencialiteti i sekretit të klientit nuk mund të garantizohet;

Dhe llojet e grantëve që mund të ekzekutohen pa ndërveprimin interaktiv me përdoruesit:

• akredite të pronarit të burimit (resource owner). Ky kyç është të përdoret vetëm kur aplikacioni klient beson tek përdoruesi dhe përdoruesi është i qetë në lidhje me futjen e emrit të përdoruesit dhe fjalëkalimit të tij. Ky lloj i qasjes duhet të përdoret vetëm në rastet kur opsionet e tjera nuk janë të disponueshme. Ky lloj i qasjes është i përshtatshëm për klientët korporativë që, brenda sistemit të tyre, tashmë e kanë përdorur informacionin e identitetit të përdoruesit dhe duan të kalojnë në OAuth 2.0.
• informacionin e klientit. Përdoren kur aplikacioni qaset në API. Kjo mund të jetë e dobishme, për shembull, kur aplikacioni dëshiron të azhurnojë informacionin e tij të regjistrimit në shërbim ose URI e ridrejtimeve, ose për të arritur në informacion tjetër që ruhet në llogarinë e aplikacionit në shërbim, përmes API të shërbimit.

scope — është një parametër i opsional. Ai përcakton fushën e shikimit. Tokeni i aksesit, i kthyer nga serveri, do t'i ofrojë qasje vetëm shërbimeve që përfshihen në këtë fushë. Pra, ne mund të bashkojmë disa shërbime nën një scope dhe nëse klienti merr çelësin e aksesit për këtë scope, ai merr qasje në të gjitha këto shërbime. Gjithashtu, scope mund të përdoret për të kufizuar të drejtat e autorizimit (për shembull, qasje për lexim ose shkruarje)

Burimi: habr.com