Shënim. përkth.: Ky artikull i mrekullueshëm nga Okta shpjegon se si OAuth dhe OIDC (OpenID Connect) funksionojnë në një mënyrë të thjeshtë dhe të qartë. Kjo njohuri do të jetë e dobishme për zhvilluesit, administratorët e sistemit, madje edhe "përdoruesit e rregullt" të aplikacioneve të njohura në internet, të cilët me shumë mundësi shkëmbejnë gjithashtu të dhëna konfidenciale me shërbime të tjera.
Në Epokën e Gurit të Internetit, shkëmbimi i informacionit ndërmjet shërbimeve ishte i lehtë. Ju thjesht i keni dhënë hyrjen dhe fjalëkalimin tuaj nga një shërbim në tjetrin, në mënyrë që ai të hynte në llogarinë tuaj dhe të merrte çdo informacion që i nevojitej.
"Më jep llogarinë tënde bankare." “Ne premtojmë se gjithçka do të jetë mirë me fjalëkalimin dhe paratë. Kjo është e sinqertë, e sinqertë!" *he hee*
Tmerr! Askush nuk duhet të kërkojë kurrë që një përdorues të ndajë një emër përdoruesi dhe fjalëkalim, kredencialet, me nje sherbim tjeter. Nuk ka asnjë garanci që organizata që qëndron pas këtij shërbimi do t'i mbajë të dhënat të sigurta dhe nuk do të mbledhë më shumë informacion personal sesa është e nevojshme. Mund të duket e çmendur, por disa aplikacione ende e përdorin këtë praktikë!
Sot ekziston një standard i vetëm që lejon një shërbim të përdorë në mënyrë të sigurt të dhënat e një tjetri. Fatkeqësisht, standarde të tilla përdorin shumë zhargone dhe terma, gjë që e ndërlikon kuptimin e tyre. Qëllimi i këtij materiali është të shpjegojë se si funksionojnë duke përdorur ilustrime të thjeshta (A mendoni se vizatimet e mia ngjajnë me lyerjen e fëmijëve? Oh mirë!).
Nga rruga, ky udhëzues është gjithashtu i disponueshëm në format video:
Zonja dhe zotërinj, mirëpresim: OAuth 2.0
është një standard sigurie që lejon një aplikacion të marrë leje për të hyrë në informacion në një aplikacion tjetër. Sekuenca e hapave për lëshimin e një leje [leje] (Ose pëlqimin [pëlqimi]) shpesh telefononi autorizimi [autorizim] ose madje autorizimi i deleguar [autorizimi i deleguar]. Me këtë standard, ju lejoni një aplikacion të lexojë të dhëna ose të përdorë funksionet e një aplikacioni tjetër në emrin tuaj pa i dhënë fjalëkalimin tuaj. Klasa!
Si shembull, le të themi se keni zbuluar një sajt të quajtur "Puna e pafat e ditës" [Puna e tmerrshme e ditës] dhe vendosi të regjistrohej në të për të marrë lojëra fjalësh të përditshme në formën e mesazheve me tekst në telefon. Ju pëlqeu shumë faqja dhe vendosët ta ndani me të gjithë miqtë tuaj. Në fund të fundit, të gjithëve u pëlqejnë lojërat e frikshme, apo jo?
“Lajmi i pafat i ditës: Keni dëgjuar për djalin që humbi gjysmën e majtë të trupit? Tani ai ka gjithmonë të drejtë!” (përkthim i përafërt, sepse origjinali ka fjalën e vet - përafërsisht përkth.)
Është e qartë se shkrimi për çdo person nga lista e kontakteve nuk është një opsion. Dhe, nëse jeni edhe pak si unë, atëherë do të bëni gjithçka për të shmangur punën e panevojshme. Për fat të mirë, Puna e tmerrshme e ditës mund të ftojë të gjithë miqtë tuaj vetë! Për ta bërë këtë, ju vetëm duhet të hapni aksesin në emailin e kontakteve tuaja - vetë faqja do t'u dërgojë atyre ftesa (rregullat e OAuth)!
“Të gjithëve u pëlqejnë lojërat e lojërave! - Jeni identifikuar tashmë? “A do të dëshironit të lejoni faqen e internetit Terrible Pun of the Day të hyjë në listën tuaj të kontakteve? - Faleminderit! Që tani e tutje, ne do t'u dërgojmë kujtime çdo ditë të gjithëve që njihni, deri në fund të kohës! Ti je shoku më i mirë!"
- Zgjidhni shërbimin tuaj të postës elektronike.
- Nëse është e nevojshme, shkoni në faqen e postës dhe regjistrohuni në llogarinë tuaj.
- Jepni lejen Terible Pun of the Day për të hyrë në kontaktet tuaja.
- Kthehuni në faqen Terible Pun of the Day.
Në rast se ndryshoni mendje, aplikacionet që përdorin OAuth ofrojnë gjithashtu një mënyrë për të anuluar aksesin. Pasi të vendosni se nuk dëshironi të ndani më kontakte me Puna e tmerrshme e ditës, mund të shkoni te faqja e postës dhe të hiqni faqen e lojërave nga lista e aplikacioneve të autorizuara.
Rrjedha OAuth
Ne sapo kemi kaluar atë që zakonisht quhet rrjedhin [rrjedha] OAuth. Në shembullin tonë, kjo rrjedhë përbëhet nga hapa të dukshëm, si dhe disa hapa të padukshëm, në të cilët dy shërbime bien dakord për një shkëmbim të sigurt informacioni. Shembulli i mëparshëm Terrible Pun of the Day përdor rrjedhën më të zakonshme të OAuth 2.0, e njohur si rrjedha e "kodit të autorizimit". [Rrjedha e "kodit të autorizimit"].
Para se të zhytemi në detajet se si funksionon OAuth, le të flasim për kuptimin e disa termave:
- Pronari i burimit:
jeni ju! Ju zotëroni kredencialet tuaja, të dhënat tuaja dhe kontrolloni të gjitha aktivitetet që mund të kryhen në llogaritë tuaja. - klient:
Një aplikacion (për shembull, shërbimi Terrible Pun of the Day) që dëshiron të aksesojë ose të kryejë veprime të caktuara në emër të Pronari i burimit'a. - Serveri i autorizimit:
Aplikacioni që di Pronari i burimit'a dhe në të cilën u Pronari i burimit'A tashmë kam një llogari. - server burimesh:
Ndërfaqja e programimit të aplikacionit (API) ose shërbimi që klient dëshiron të përdorë në emër Pronari i burimit'a. - Ridrejto URI:
Lidhja që Serveri i autorizimit do të ridrejtojë Pronari i burimit'dhe pas dhënies së lejes klient'në. Nganjëherë referohet si "URL-ja e kthimit të telefonatës". - Lloji i përgjigjes:
Lloji i informacionit që pritet të merret klient. Më e zakonshme Lloji i përgjigjes'ohm është kodi, domethënë klient pret të marrë Kodi i autorizimit. - Fusha:
Ky është një përshkrim i detajuar i lejeve që kërkohen klient'y, të tilla si qasja në të dhëna ose kryerja e veprimeve të caktuara. - Pëlqim:
Serveri i autorizimit beretë Scopeskërkuar klient'Om, dhe pyet Pronari i burimit'a, a është ai gati të sigurojë klient'kanë lejet e duhura. - ID e klientit:
Ky ID përdoret për të identifikuar klient'a on Serveri i autorizimit'e. - Sekreti i klientit:
Ky është fjalëkalimi që dihet vetëm klient'u dhe Serveri i autorizimit'në. Kjo i lejon ata të ndajnë informacion privatisht. - Kodi i autorizimit:
Kodi i përkohshëm me një periudhë të shkurtër vlefshmërie, i cili klient ajo siguron Serveri i autorizimit'y në këmbim të Qasja Token. - Qasja Token:
Çelësi që klienti do të përdorë për të komunikuar server burimesh'om. Një lloj distinktiv ose kartë kyçe që ofron klient'kanë leje për të kërkuar të dhëna ose për të kryer veprime në server burimeshnë emrin tuaj.
Shënim: Ndonjëherë Serveri i Autorizimit dhe Serveri i Burimeve janë i njëjti server. Megjithatë, në disa raste, këta mund të jenë serverë të ndryshëm, edhe nëse nuk i përkasin të njëjtës organizatë. Për shembull, Serveri i Autorizimit mund të jetë një shërbim i palës së tretë i besuar nga Serveri i Burimeve.
Tani që kemi mbuluar konceptet thelbësore të OAuth 2.0, le të kthehemi te shembulli ynë dhe të hedhim një vështrim më të afërt se çfarë ndodh në rrjedhën e OAuth.
- Ti, Pronari i burimit, ju dëshironi të ofroni shërbimin Terrible Pun of the Day (klienty) qasje në kontaktet tuaja në mënyrë që ata të mund të dërgojnë ftesa për të gjithë miqtë tuaj.
- klient ridrejton shfletuesin në faqe Serveri i autorizimit'a dhe përfshini në pyetje ID e klientit, Ridrejto URI, Lloji i përgjigjes dhe një ose më shumë Scopes (lejet) që i duhen.
- Serveri i autorizimit ju verifikon, duke kërkuar një emër përdoruesi dhe fjalëkalim nëse është e nevojshme.
- Serveri i autorizimit shfaq një formular Pëlqim (konfirmimet) me një listë të të gjithave Scopeskërkuar klient'om. Ju bini dakord ose refuzoni.
- Serveri i autorizimit ju ridrejton në sit klient'a, duke përdorur Ridrejto URI me Kodi i autorizimit (Kodi i autorizimit).
- klient komunikon drejtpërdrejt me Serveri i autorizimit'ohm (duke anashkaluar shfletuesin Pronari i burimit'a) dhe dërgon në mënyrë të sigurt ID e klientit, Sekreti i klientit и Kodi i autorizimit.
- Serveri i autorizimit kontrollon të dhënat dhe përgjigjet me Qasja Token'om (token aksesi).
- Tani klient mund të përdorin Qasja Token për të dërguar një kërkesë tek server burimesh për të marrë një listë të kontakteve.
ID-ja dhe sekreti i klientit
Shumë kohë përpara se të lejonit "Terrible Pun of the Day" të hynte në kontaktet tuaja, Klienti dhe Serveri i Autorizimit kishin krijuar një marrëdhënie pune. Serveri i autorizimit gjeneroi ID-në e klientit dhe sekretin e klientit (ndonjëherë thirrur ID-ja e aplikacionit и Sekreti i aplikacionit) dhe i dërgoi ato te Klienti për ndërveprim të mëtejshëm brenda OAuth.
"- Përshëndetje! Unë do të doja të punoja me ju! - Sigurisht, nuk është problem! Këtu janë ID-ja dhe Sekreti juaj i Klientit!”
Emri nënkupton që Sekreti i Klientit duhet të mbahet sekret në mënyrë që vetëm Klienti dhe Serveri i Autorizimit ta dinë atë. Në fund të fundit, është me ndihmën e tij që Serveri i Autorizimit konfirmon të vërtetën e Klientit.
Por kjo nuk është e gjitha... Ju lutemi mirëpresim OpenID Connect!
OAuth 2.0 është krijuar vetëm për autorizimi - për të siguruar akses në të dhëna dhe funksione nga një aplikacion në tjetrin. (OIDC) është një shtresë e hollë në krye të OAuth 2.0 që shton të dhënat e hyrjes dhe të profilit të përdoruesit që është regjistruar në llogari. Organizimi i një sesioni identifikimi shpesh quhet si vërtetimi [autentifikimi], dhe informacione rreth përdoruesit të regjistruar në sistem (d.m.th. rreth Pronari i burimit'e), - te dhena Personale [identiteti]. Nëse Serveri i Autorizimit mbështet OIDC, ai nganjëherë referohet si ofruesi i të dhënave personale [ofruesi i identitetit]sepse siguron klient'Ka informacion rreth Pronari i burimit'e.
OpenID Connect ju lejon të zbatoni skenarë ku një hyrje e vetme mund të përdoret në shumë aplikacione - kjo qasje njihet gjithashtu si hyrje e vetme (SSO). Për shembull, një aplikacion mund të mbështesë integrimin e SSO me rrjetet sociale si Facebook ose Twitter, duke i lejuar përdoruesit të përdorin një llogari që tashmë kanë dhe preferojnë ta përdorin.
Rrjedha (rrjedha) OpenID Connect duket e njëjtë si në rastin e OAuth. I vetmi ndryshim është se në kërkesën parësore, shtrirja specifike e përdorur është openid, - A klient përfundimisht bëhet si Qasja TokenDhe Shenja ID.
Ashtu si në rrjedhën OAuth, Qasja Token në OpenID Connect, kjo është një vlerë që nuk është e qartë klient'në. Nga pikëpamja klient'a Qasja Token përfaqëson një varg karakteresh që përcillet së bashku me secilën kërkesë server burimesh'y, e cila përcakton nëse shenja është e vlefshme. Shenja ID përfaqëson një gjë krejtësisht të ndryshme.
Token ID është një JWT
Shenja ID është një varg karakteresh i formatuar posaçërisht i njohur si JSON Web Token ose JWT (nganjëherë shenjat JWT shqiptohen si "jots"). Vëzhguesve të jashtëm, JWT mund të duket si koprraci e pakuptueshme, por klient mund të nxjerrë informacione të ndryshme nga JWT, si ID, emrin e përdoruesit, kohën e hyrjes, datën e skadimit Shenja ID'a, prania e përpjekjeve për të ndërhyrë në JWT. Të dhënat brenda Shenja ID'a quhen aplikacionet [pretendimet].
Në rastin e OIDC, ekziston gjithashtu një mënyrë standarde me të cilën klient mund të kërkojë informacion shtesë për individin [identiteti] nga Serveri i autorizimit'një, për shembull, një adresë emaili duke përdorur Qasja Token.
Mësoni më shumë rreth OAuth dhe OIDC
Pra, ne rishikuam shkurtimisht se si funksionojnë OAuth dhe OIDC. Gati për të gërmuar më thellë? Këtu janë burime shtesë për t'ju ndihmuar të mësoni më shumë rreth OAuth 2.0 dhe OpenID Connect:
Si gjithmonë, mos ngurroni të komentoni. Për të qenë të azhurnuar me lajmet tona më të fundit, abonohuni në и Okta për zhvilluesit!
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com