Me këtë postim dua të hap një seri artikujsh kushtuar IdentityServer4. Do të fillojmë me konceptet bazë.
Protokolli më premtues i autentikimit në këtë moment është , ndërsa protokolli i autorizimit (dhënies së aksesit) është . zbaton këto dy protokolle. Ai është i optimizuar për zgjidhjen e problemeve tipike të sigurisë.
â Ă«shtĂ« njĂ« protokoll dhe standard autentikimi; ai nuk jep akses te burimet (Web API), por meqĂ« Ă«shtĂ« ndĂ«rtuar mbi protokollin e autorizimit , ai ju lejon tĂ« merrni parametrat e profilit tĂ« pĂ«rdoruesit sikur tĂ« kishit marrĂ« akses te burimi .
(JSON Web Token) është një standard web që përcakton mënyrën e transmetimit të të dhënave të përdoruesit në format JSON në formë të enkriptuar.
â Ă«shtĂ« njĂ« protokoll dhe standard autorizimi. Ai u lejon aplikacioneve tĂ« marrin akses nĂ« burime tĂ« mbrojtura, pĂ«r shembull te Web API.
Le t'i hedhim një sy diagramit të qasjes në një burim të mbrojtur dhe të shqyrtojmë hapat kryesorë si edhe terminologjinë e përdorur:
Klienti i kĂ«rkon pĂ«rdoruesit leje pĂ«r tĂ« kaluar autorizimin nĂ« emrin e tij. KÎ»ÎŻÎżÏ ent â Ă«shtĂ« njĂ« aplikacion klient qĂ« qaset nĂ« burime tĂ« mbrojtura nĂ« emĂ«r tĂ« pronarit tĂ« burimeve. Burimi â janĂ« tĂ« gjitha shĂ«rbimet tona tĂ« mbrojtura .
User i lejon aplikacionit klient tĂ« kalojĂ« autorizimin nĂ« emrin e tij, pĂ«r shembull duke futur login dhe fjalĂ«kalimin. Login-i dhe fjalĂ«kalimi do tĂ« shĂ«rbejnĂ« si grant autorizimi pĂ«r aplikacionin klient. User (pronari i burimit) â Ă«shtĂ« njĂ« program ose njĂ« person qĂ« mund tĂ« japĂ« akses nĂ« burime tĂ« mbrojtura, pĂ«r shembull duke futur login-in (username) dhe fjalĂ«kalimin (password);
Aplikacioni klient kërkon token-in e aksesit nga
IdentityServer4duke dhënë informacion për veten (client_id,client_secret), duke paraqitur lejen e autorizimit nga përdoruesi (username,password) dhe duke dhënëgrant_typedhescope. Më pas serveri i autorizimit verifikon autenticitetin e klientit dhe kredencialet e pronarit të burimit (login-in dhe fjalëkalimin).Protokolli OAuth 2.0 kryen autentikimin jo vetëm të përdoruesit, por edhe të aplikacionit klient që po qaset në burime. Për këtë, protokolli parashikon parametra të tillë si client_id dhe client_secret.
Ńlient_id â Ă«shtĂ« identifikuesi i aplikacionit klient, i pĂ«rdorurIdentityServer4pĂ«r tĂ« gjetur informacion rreth klientit.
client_secret Ă«shtĂ« analog i fjalĂ«kalimit pĂ«r aplikacionin klient dhe pĂ«rdoret pĂ«r autentikimin e aplikacionit klient nĂ«IdentityServer4. Sekreti i klientit duhet tĂ« njihet vetĂ«m nga aplikacioni dhe API. Nga sa u tha mĂ« sipĂ«r, arrijmĂ« nĂ« pĂ«rfundimin se IdentityServer4 duhet tâi njohĂ« klientĂ«t e vet.NĂ«se autenticiteti i aplikacionit Ă«shtĂ« konfirmuar dhe leja e autorizimit Ă«shtĂ« e vlefshme,
IdentiryServer4krijonaccess-token(token aksesi) për aplikacionin dhe një çelës rifreskimi opsional (refresh-token). Procesi i autorizimit ka përfunduar. Nëse kërkesa është e pavlefshme ose e paautorizuar, atëherë serveri i autorizimit kthen një kod me mesazhin përkatës të gabimit.Aplikacioni klient kërkon të dhëna nga Web API i mbrojtur, duke paraqitur tokenin e aksesit për autorizim. Nëse kodi i përgjigjes së serverit të burimeve është , ose , atëherë tokeni i aksesit i përdorur për autentikim është i pavlefshëm ose ka skaduar.
Nëse tokeni është i vlefshëm,
Web APIi jep të dhënat aplikacionit.
Llojet e tokenëve
Klientëve të regjistruar në IdentityServer4 u lejohet të kërkojnë nga IdentityServer4 identity-token, access-token dhe refresh-token.
- identity-token (token identifikimi) â rezultati i procesit tĂ« autentikimit. PĂ«rmban identifikuesin e pĂ«rdoruesit dhe informacion se si dhe kur pĂ«rdoruesi kalon autentikimin. Mund tĂ« zgjerohet me tĂ« dhĂ«nat tuaja.
- access-token (token aksesi) â i dĂ«rgohet API-sĂ« sĂ« mbrojtur dhe pĂ«rdoret prej saj pĂ«r autorizim (lejim aksesi) nĂ« tĂ« dhĂ«nat e veta.
- refresh-token (token rifreskimi) â njĂ« parametĂ«r opsional qĂ« serveri i autorizimit mund ta kthejĂ« si pĂ«rgjigje ndaj kĂ«rkesĂ«s pĂ«r token aksesi.
Le të prezantojmë edhe dy koncepte të tjera:
Authenticatation Server Url â pika fundore pĂ«r marrjen e çelĂ«sit tĂ« aksesit. TĂ« gjitha kĂ«rkesat pĂ«r lĂ«shimin dhe rinovimin e çelĂ«save tĂ« aksesit do tâi dĂ«rgojmĂ« nĂ« kĂ«tĂ« URL.
Resource Url â URL-ja e burimit tĂ« mbrojtur, tĂ« cilĂ«n duhet ta pĂ«rdorni pĂ«r tĂ« marrĂ« akses nĂ« tĂ«, duke i dĂ«rguar çelĂ«sin e aksesit nĂ« header-in 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 fundore IdentityServer4 me header-in e mëposhtëm
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'dhe duke kaluar 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 janë shqyrtuar më sipër. Le të shqyrtojmë parametrat e tjerë:
grant_type â lloji i grantit ose lloji i autorizimit. Lloji i autorizimit varet nga metoda qĂ« aplikacioni pĂ«rdor pĂ«r tĂ« kĂ«rkuar autorizim, si edhe nga llojet e autorizimit qĂ« mbĂ«shteten nga API. NĂ« rastin tonĂ« ai do tĂ« ketĂ« vlerĂ«n password, e cila sipas specifikimit OAuth 2.0 i korrespondon grantit me kredencialet e pronarit tĂ« burimit (autorizim me hyrje dhe fjalĂ«kalim).
Protokolli OAuth 2.0 përcakton llojet e mëposhtme të granteve që kërkojnë ndërveprim të detyrueshëm me përdoruesin:
- kodi i autorizimit (authorization code). ĂshtĂ« njĂ« nga llojet mĂ« tĂ« zakonshme tĂ« autorizimit, pasi pĂ«rshtatet mirĂ« pĂ«r aplikacionet server-side, ku kodi burimor i aplikacionit dhe sekreti i klientit nuk janĂ« tĂ« qasshĂ«m pĂ«r palĂ« tĂ« treta;
- i nënkuptuar (implicit). Lloji i nënkuptuar i autorizimit përdoret nga aplikacionet mobile dhe web, ku konfidencialiteti i sekretit të klientit nuk mund të garantohet;
Dhe llojet e granteve që mund të ekzekutohen pa ndërveprim interaktiv me përdoruesin:
- kredencialet e pronarit të burimit (resource owner). Ky lloj autorizimi duhet të përdoret vetëm kur aplikacioni klient gëzon besimin e përdoruesit dhe përdoruesi nuk ka shqetësim të fusë hyrjen dhe fjalëkalimin e tij. Ky lloj autorizimi duhet të përdoret vetëm kur opsionet e tjera nuk janë të disponueshme. Ky lloj autorizimi është i përshtatshëm për klientët korporativë që tashmë kanë përdorur kredencialet e përdoruesit brenda sistemit të tyre dhe duan të kalojnë në
OAuth 2.0. - kredencialet e klientit. Përdoren kur aplikacioni hyn në API. Kjo mund të jetë e dobishme, për shembull, kur aplikacioni dëshiron të përditësojë informacionin e vet të regjistrimit në shërbim ose URI-në e ridrejtimit, ose të ketë qasje në informacione të tjera të ruajtura në llogarinë e aplikacionit në shërbim përmes API-së së shërbimit.
scope â Ă«shtĂ« njĂ« parametĂ«r opsional. Ai pĂ«rcakton fushĂ«n e veprimit. Token-i i aksesit i kthyer nga serveri do tĂ« japĂ« qasje vetĂ«m te shĂ«rbimet qĂ« pĂ«rfshihen nĂ« kĂ«tĂ« scope. Pra, mund tĂ« bashkojmĂ« disa shĂ«rbime nĂ«n njĂ« scope tĂ« vetĂ«m dhe, nĂ«se klienti merr njĂ« çelĂ«s aksesi pĂ«r kĂ«tĂ« scope, ai fiton qasje nĂ« tĂ« gjitha kĂ«to shĂ«rbime. Scope mund tĂ« pĂ«rdoret gjithashtu pĂ«r tĂ« kufizuar tĂ« drejtat e autorizimit (pĂ«r shembull, qasje vetĂ«m pĂ«r lexim ose pĂ«r shkrim)
Burimi: habr.com
