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ë , dhe protokolli për autorizim (dhënie aksesit) është . implementon këto dy protokolle. Ai është optimizuar për të zgjidhur problemet tipike të sigurisë.
â ky Ă«shtĂ« njĂ« protokoll dhe standard autentifikimi, ai nuk jep akses nĂ« burime (Web API), por pasi Ă«shtĂ« zhvilluar mbi protokollin e autorizimit , ai lejon marrjen e parametrave tĂ« profilit tĂ« pĂ«rdoruesit siç do tĂ« kishit marrĂ« akses nĂ« burimin .
(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.
â 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:
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 .
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);
Aplikacioni klient kërkon një token qasje nga
IdentityServer4duke ofruar informacion mbi veten (client_id,client_secret), duke ofruar lejen për autorizim nga përdoruesi (username,password) dhe duke ofruargrant_typedhescope. 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Ă«rdoretIdentityServer4pĂ«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.Nëse autenticiteti i aplikacionit konfirmohet dhe leja për autorizim është e vlefshme,
IdentiryServer4krijontoken-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.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 , ose , atëherë token-i i aksesit i përdorur për autentifikim është i pavlefshëm ose i skaduar.
Nëse token-i është i vlefshëm,
Web APIofron 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
