Me këtë postim, do të doja të hapja një seri artikujsh kushtuar IdentityServer4. Do të fillojmë me konceptet bazë.
Protokolli më premtues i vërtetimit për momentin është , dhe protokolli i autorizimit (që ofron akses) është . zbaton këto dy protokolle. Është optimizuar për të zgjidhur probleme tipike sigurinë.
— është një protokoll dhe standard vërtetimi, nuk ofron qasje në burime (Web API), por meqenëse është zhvilluar mbi protokollin e autorizimit , ju lejon të merrni parametrat e profilit të përdoruesit sikur të kishit aksesuar burimin .
(JSON Web Token) është një standard web që përcakton një mënyrë për të transmetuar të dhënat e përdoruesit në formatin JSON të enkriptuar.
është një protokoll dhe standard autorizimi. Ai u lejon aplikacioneve të hyjnë në burime të mbrojtura, siç janë API-të e Uebit.
Le të hedhim një vështrim në një diagram të qasjes në një burim të mbrojtur dhe të kuptojmë hapat kryesorë dhe terminologjinë e pranuar:
-
Klienti kërkon leje nga përdoruesi për t'u kyçur në emrin e tij. klient — është një aplikacion klienti që qaset në burimet e mbrojtura në emër të pronarit të burimit. burime — këto janë të gjitha shërbimet tona të sigurta .
-
Përdoruesi autorizon aplikacionin e klientit të autorizojë në emrin e tij, për shembull, duke futur emrin e përdoruesit dhe fjalëkalimin e tij. Ky emër përdoruesi dhe fjalëkalimi do të shërbejnë si grant autorizimi për aplikacionin e klientit. Përdoruesi (pronari i burimit) — një program ose person që mund të japë akses në burimet e mbrojtura, për shembull, duke futur një hyrje (emër përdoruesi) dhe fjalëkalim (fjalëkalim);
-
Aplikacioni i klientit kërkon një shenjë aksesi nga
IdentityServer4duke dhënë informacion rreth vetes (client_id,client_secret), duke dhënë leje autorizimi nga përdoruesi (username,password) dhe dispozitëgrant_typeиscopeServeri i autorizimit më pas verifikon vërtetësinë e klientit dhe kredencialet e pronarit të burimit (hyrjen dhe fjalëkalimin).Protokolli OAuth 2.0 autentifikon jo vetëm përdoruesin, por edhe aplikacionin e klientit që qaset në burime. Për këtë qëllim, protokolli ofron parametra të tillë si client_id и sekret_i_klientit.
client_id — është identifikuesi i aplikacionit të klientit i përdorurIdentityServer4për të kërkuar informacion në lidhje me një klient.
sekret_i_klientit është një analog i një fjalëkalimi për aplikacionin e klientit dhe përdoret për të autentifikuar aplikacionin e klientit nëIdentityServer4. Sekreti i klientit duhet të jetë i njohur vetëm për aplikacionin dhe API-n.Bazuar në sa më sipër, konkludojmë se IdentityServer4 duhet të dijë për klientët e tij. -
Nëse aplikacioni është i autentifikuar dhe leja e autorizimit është e vlefshme,
IdentiryServer4krijonaccess-токен(shenjë aksesi) për aplikacionin dhe një çelës opsional për rifreskim (refresh-токенProcesi i autorizimit ka përfunduar. Nëse kërkesa është e pavlefshme ose e paautorizuar, serveri i autorizimit kthen një kod me një mesazh gabimi përkatës. -
Aplikacioni i klientit kërkon të dhëna nga një API i sigurt në internet, duke ofruar një shenjë aksesi për autorizim. Nëse kodi i përgjigjes së serverit të burimeve , ose , atëherë tokeni i aksesit i përdorur për autentifikim është i pavlefshëm ose i skaduar.
-
Nëse tokeni është i vlefshëm,
Web APIi jep të dhëna aplikacionit.
Llojet e tokenëve
I regjistruar në IdentityServer4 klientët lejohen të kërkojnë nga IdentityServer4 identity-shenjë, access-shenjë dhe refresh-shenjë.
- shenjë identiteti — rezultati i procesit të vërtetimit. Përmban ID-në e përdoruesit dhe informacion se si dhe kur përdoruesi vërtetohet. Mund të zgjerohet me të dhënat tuaja.
- token qasjeje — i kalohet API-t të mbrojtur dhe përdoret prej tij për të autorizuar (lejuar qasje) në të dhënat e tij.
- token rifreskimi — një parametër opsional që serveri i autorizimit mund ta kthejë në përgjigje të një kërkese për token aksesi.
Le të prezantojmë dy koncepte të tjera:
URL-ja e serverit të autentifikimit — pika fundore për marrjen e një çelësi qasje. Të gjitha kërkesat për çelësa qasje do të dërgohen në këtë URL.
URL-ja e burimit — URL-ja e burimit të mbrojtur që duhet të aksesohet duke kaluar çelësin e aksesit në kokën e Autorizimit.
Kërko një çelës qasjeje
Për të kërkuar një çelës aksesi, klienti bën POST kërkesë për pikën fundore IdentityServer4 me titullin 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 и client_secret u diskutuan më sipër. Le të shohim parametrat e mbetur:
lloji_i_grantit — lloji i dhënies ose lloji i lejes së autorizimit. Lloji i lejes së autorizimit varet nga metoda e kërkesës së autorizimit e përdorur nga aplikacioni, si dhe nga llojet e lejeve të mbështetura nga API. Në rastin tonë, do të jetë password, e cila sipas specifikimit OAuth 2.0 korrespondon me dhënien e detajeve të aksesit të pronarit të burimit (autorizimi me anë të hyrjes dhe fjalëkalimit).
Protokolli OAuth 2.0 identifikon llojet e mëposhtme të granteve që kërkojnë ndërveprim i detyrueshëm me përdoruesit:
- kodi i autorizimitËshtë një nga llojet më të zakonshme të lejeve të autorizimit, pasi është shumë i përshtatshëm për aplikacionet nga ana e serverit, ku kodi burimor i aplikacionit dhe sekreti i klientit nuk janë të arritshëm për të jashtmit;
- i nënkuptuarLloji i lejes së autorizimit implicit përdoret nga aplikacionet mobile dhe web ku konfidencialiteti i sekretit të klientit nuk mund të garantohet;
Dhe llojet e granteve që mund të kryhet pa ndërveprim interaktiv me përdoruesit:
- detajet e pronarit të burimitKy lloj lejeje duhet të përdoret vetëm nëse aplikacioni i klientit është i besuar nga përdoruesi dhe përdoruesi ndihet rehat të fusë emrin e përdoruesit dhe fjalëkalimin e tij. Ky lloj lejeje duhet të përdoret vetëm kur opsionet e tjera nuk janë të disponueshme. Ky lloj lejeje është i përshtatshëm për klientët e korporatave që kanë përdorur tashmë kredencialet e përdoruesit brenda sistemit të tyre dhe duan të migrojnë në
OAuth 2.0. - kredencialet e klientitKëto përdoren kur një aplikacion hyn në një API. Kjo mund të jetë e dobishme, për shembull, kur një aplikacion dëshiron të përditësojë informacionin e vet të regjistrimit në një shërbim ose një URI ridrejtimi, ose të hyjë në informacione të tjera të ruajtura në llogarinë e aplikacionit në shërbim nëpërmjet API-t të shërbimit.
Shtrirja — Ky është një parametër opsional. Ai përcakton fushëveprimin. Tokeni i aksesit i kthyer nga serveri do të ofrojë akses vetëm në shërbimet brenda atij fushëveprimi. Kjo do të thotë që ne mund të grupojmë disa shërbime nën një fushëveprim të vetëm, dhe nëse një klient merr një çelës aksesi për atë fushëveprim, ai fiton akses në të gjitha ato. Fusha mund të përdoret gjithashtu për të kufizuar të drejtat e autorizimit (për shembull, akses leximi ose shkrimi).
Burimi: www.habr.com
