Shën. përkth.: Në këtë material të shkëlqyer nga kompania Okta, shpjegohen thjesht dhe në mënyrë vizuale parimet e funksionimit të OAuth dhe OIDC (OpenID Connect). Këto njohuri do të jenë të dobishme për zhvilluesit, administratoret e sistemeve dhe madje edhe për "përdoruesit e zakonshëm" të aplikacioneve të njohura në internet, të cilët me siguri shkëmbejnë gjithashtu të dhëna konfidenciale me shërbime të tjera.
Në "epokën e gurit" të internetit, ndarja e informacionit midis shërbimeve ishte e lehtë. Ju thjesht i jepnit emrin tuaj dhe fjalëkalimin e një shërbimi tjetri, që të hynte në llogarinë tuaj dhe të merrte çdo informacion të nevojshëm.
"Jepni tuajin llogari bankar." â "PremtojmĂ« se me fjalĂ«kalimin dhe paratĂ« gjithçka do tĂ« jetĂ« nĂ« rregull. Ja, me tĂ« vĂ«rtetĂ« tĂ« sinqertĂ«!" *hi-hi*
E frikshme! Askush dhe asnjëherë nuk duhet të kërkojë nga përdoruesi të ndajë emrin dhe fjalëkalimin e tij, të dhënat e tij identifikues, me një shërbim tjetër. Nuk ka asnjë garantim se organizata që qëndron pas këtij shërbimi do të ruajë të dhënat në siguri dhe nuk do të mbledhë më shumë informacion personal se sa nevojitet. Mund të duket e çuditshme, por disa aplikacione ende përdorin një praktikë të tillë!
Sot ka një standard të vetme që lejon një shërbim të përdorë në mënyrë të sigurt të dhënat e një shërbimi tjetër. Fatkeqësisht, standardet e tilla përdorin shumë gjuhë të specializuar dhe termine, që e ndërlikojnë kuptimin e tyre. Qëllimi i këtij materiali është të shpjegojë se si funksionojnë ato me ilustrime të thjeshta (Mendoni se vizatimet e mia duken si një vizatim fëmijësh? Mirë, nuk ka problem!).
Për rast, ky udhëzues është gjithashtu i disponueshëm në formë video:
Dhurues dhe zotërinj, mirëseardhët: OAuth 2.0
â Ă«shtĂ« njĂ« standard sigurie qĂ« lejon njĂ« aplikacion tĂ« marrĂ« lejen pĂ«r tĂ« aksesuar informacionin nĂ« njĂ« aplikacion tjetĂ«r. Radhitja e veprimeve pĂ«r dhĂ«nien e lejes [permission] (ose lejes [consent]) shpesh quhet autorizim [authorization] apo madje autorizim tĂ« deleguar [delegated authorization]. Me kĂ«tĂ« standard ju lejoni qĂ« aplikacioni tĂ« lexojĂ« tĂ« dhĂ«na ose tĂ« pĂ«rdorĂ« funksionet e njĂ« aplikacioni tjetĂ«r nĂ« emrin tuaj, pa iu treguar atij fjalĂ«kalimin tuaj. Super!
Si një shembull, imagjinoni se keni zbuluar një website me emrin "Shaka e Dites" [Terrible Pun of the Day] dhe vendosët të regjistroheni në të, për të marrë daily kalamburë në formën e mesazheve tekstual në telefon. Kjo faqe ju pëlqeu shumë, dhe vendosët ta ndani me të gjithë miqtë tuaj. Sepse kalamburët e çuditshëm iu pëlqejnë të gjithëve, apo jo?
«Kalamburi i dĂ«shtuar i ditĂ«s: DĂ«gjuat pĂ«r djalin qĂ« humbi gjysmĂ«n e majtĂ« tĂ« trupit? Tani ai Ă«shtĂ« gjithmonĂ« e djathta!» (pĂ«rkthimi Ă«shtĂ« i afĂ«rt, sepse origjinali ka lojĂ« fjalĂ«sh â shĂ«n. pĂ«rkth.)
E qartĂ«, qĂ« tĂ« shkruash çdo personi nĂ« listĂ«n e kontakteve nuk Ă«shtĂ« njĂ« opsion. Dhe, nĂ«se jeni tĂ« paktĂ«n pak si unĂ«, do tĂ« bĂ«ni gjithçka pĂ«r tĂ« shmangur punĂ«n e tepĂ«rt. FatmirĂ«sisht, Terrible Pun of the Day mund tĂ« ftojĂ« tĂ« gjithĂ« miqtĂ« tuaj vetĂ«! Mjafton t'i hapni aksesin e emailit tĂ« kontakteve â faqja do t'i dĂ«rgojĂ« vetĂ« ftesat (OAuth Ă«shtĂ« tĂ«rheqĂ«s)!
«TĂ« gjithĂ« e duan kalamburin! â A jeni regjistruar? â Doni t'i hapni akses faqes Terrible Pun of the Day pĂ«r listĂ«n e kontakteve? â Faleminderit! Tani ne do t'ju dĂ«rgojmĂ« kujtesa çdo ditĂ« pĂ«r tĂ« gjithĂ« qĂ« njihni, deri nĂ« pĂ«rfundim tĂ« epokave! Ju jeni shoku mĂ« i mirĂ«!»
- Zgjidhni shërbimin tuaj të postës elektronike.
- Nëse është e nevojshme, shkoni në faqen e postës dhe bëni login në llogarinë tuaj.
- Jepni lejen faqes Terrible Pun of the Day për aksesin në kontaktet.
- Kthehuni në faqen e Terrible Pun of the Day.
Në rast se ndryshoni mendje, aplikacionet që përdorin OAuth gjithashtu ofrojnë një mënyrë për të anuluar aksesin. Nëse vendosni që nuk dëshironi më të ndani kontaktet me Terrible Pun of the Day, mund të shkoni në faqen e postës dhe të hiqni faqen me kalamburë nga lista e aplikacioneve të autorizuar.
PĂ«rgj Flow
Pak sapo kaluam në atë që zakonisht quhet rrjedha [flow] OAuth. Në shembullin tonë, kjo rrjedhë përbëhet nga hapa të dukshëm, si dhe disa hapa të padukshëm, në të cilat dy shërbime bien dakord për një shkëmbim të sigurt informacioni. Në shembullin e mëparshëm me Terrible Pun of the Day, përdoret rrjedha më e njohur OAuth 2.0, e njohur si rrjedha 'me kodin e autorizimit' [«authorization code» flow].
Para se të shkojmë në detaje për funksionimin e OAuth, le të flasim për kuptimin e disa termave:
- Pronari i Burimeve:
Jeni ju! Ju zotëroni kredencialet tuaja, të dhënat tuaja dhe menaxhoni të gjitha veprimet që mund të bëhen me llogaritë tuaja. - Client:
Një aplikacion (p.sh., shërbimi Terrible Pun of the Day) që dëshiron të ketë akses ose të kryejë veprime në emër Pronari i Burimevetij. - Serveri i Autorizimit:
Një aplikacion që di Pronari i Burimevetë tij dhe në të cilin Pronari i Burimevetij tashmë i ka një llogari. - Serveri Burimor:
Një ndërfaqe aplikacioni (API) ose shërbim që Client dëshiron të përdorë në emër Pronari i Burimevetij. - URI e Ridrejtimit:
Një lidhje, në të cilën Serveri i Autorizimit do të ridrejtohet Pronari i Burimevetij pasi të ofrohet leja Clienttij. Ndonjëherë quhet "URL i Kthimit". - Tipi i Përgjigjes:
Tipi i informacionit që pritet të marrë Client. Llohi më i zakonshëm Tipi i Përgjigjesi tij është kodi, domethënë Client përshtatet për të marrë Kodi i Autorizimit. - Shkalla:
Ky është një përshkrim i detajuar i lejeve që kërkohen Clienttij, si akses në të dhëna ose kryerjen e veprimeve të caktuara. - Bashkëngjitje:
Serveri i Autorizimit merr Shkallët, të kërkuar Clienttij, dhe i kërkon Pronari i Burimevetij, nëse është i gatshëm të japë Clienttij lejet përkatëse. - ID e Klientit:
Ky ID përdoret për të identifikuar Clienttij në Serveri i Autorizimitnjë. - Sekreti i Klientit:
Ky është një fjalëkalim që dihet vetëm nga Clienttij dhe Serveri i Autorizimittij. Ai u lejon atyre të shkëmbejnë informacion në mënyrë konfidenciale. - Kodi i Autorizimit:
Një kod temporar me një periudhë të vogël vlefshmërie që Client ofron Serveri i Autorizimitpërdoret për të marrë Tokenin e Aksesit. - Tokenin e Aksesit:
Një çelës që ndihmon klientin të komunikojë me Serveri Burimortij. Një lloj badge ose çelës-kartë që ofron Clienttij leje për të kërkuar të dhëna ose për të kryer veprime në Serveri Burimoremrin tuaj.
Shënim: ndonjëherë Serveri i Autorizimit dhe Serveri Burimor janë të njëjtin server. Megjithatë, në disa raste, ata mund të jenë servera të ndryshëm, madje të mos jenë nën të njëjtën organizatë. Për shembull, Serveri i Autorizimit mund të jetë një shërbim i palës së tretë që beson Serveri Burimor.
Tani që jemi njohur me konceptet bazike të OAuth 2.0, le të kthehemi në shembullin tonë dhe të shqyrtojmë më në detaje se çfarë ndodh në rrjedhën e OAuth.
- Ju, Pronari i Burimeve, dëshiron të ofrojë shërbimit Terrible Pun of the Day (Clienttij) akses në kontaktet tuaja që ai të mund të dërgojë ftesa të gjithë miqve tuaj.
- Client ndërsa ridrejton shfletuesin në faqen Serveri i Autorizimittij dhe përfshin në kërkesë ID e Klientit, URI e Ridrejtimit, Tipi i Përgjigjes një ose më shumë Shkallët (leje) që i nevojiten.
- Serveri i Autorizimit verifikon ju, duke kërkuar nëse është e nevojshme emrin dhe fjalëkalimin.
- Serveri i Autorizimit paraqet një formë Bashkëngjitje (konfirmimi) me një listë të gjitha Shkallët, të kërkuar Clienttij. Ju pranoni ose refuzoni.
- Serveri i Autorizimit ridrejton ju në faqen e internetit Clienttij, duke përdorur URI e Ridrejtimit më bashkë me Kodi i Autorizimit (kodin e autorizimit).
- Client direkt lidhjet me Serveri i Autorizimittij (përmes shfletuesit Pronari i Burimevetij) dhe dërgon informacionin në mënyrë të sigurt. ID e Klientit, Sekreti i Klientit dhe Kodi i Autorizimit.
- Serveri i Autorizimit kontrollon tĂ« dhĂ«nat dhe pĂ«rgjigjet me Tokenin e AksesitâtĂ« (tokeni i aksesit).
- tregon atë që pritej: Client mund të përdorë Tokenin e Aksesit për të dërguar një kërkesë për Serveri Burimor për të marrë një listë kontakti.
Client ID dhe Secret
MĂ« parĂ« se ta lejonit Terrible Pun of the Day tĂ« merrni akses nĂ« kontaktet, Client dhe Authorization Server krijuan njĂ« marrĂ«veshje. Authorization Server gjeneroi Client ID dhe Client Secret (ndonjĂ«herĂ« quhen App ID dhe App Secret) dhe ia dĂ«rgoi Clientâit pĂ«r komunikim tĂ« mĂ«tejshĂ«m nĂ« kuadĂ«r tĂ« OAuth.
«â PĂ«rshĂ«ndetje! Doja tĂ« punoja me ty! â Aspak problem! Ja Client ID dhe Secret!»
Emri sugjeron se Client Secret duhet tĂ« mbahet nĂ« fshehtĂ«si, nĂ« mĂ«nyrĂ« qĂ« tĂ« dihet vetĂ«m nga Client dhe Authorization Server. Sepse, me ndihmĂ«n e tij, Authorization Server vĂ«rteton autenticitetin e Clientâit.
Por kjo nuk është e gjitha⊠Ju lutem, mirëpriteni OpenID Connect!
OAuth 2.0 Ă«shtĂ« krijuar vetĂ«m pĂ«r tĂ« autorizimit â pĂ«r tĂ« ofruar akses nĂ« tĂ« dhĂ«na dhe funksione nga njĂ« aplikacion nĂ« njĂ« tjetĂ«r. (OIDC) â Ă«shtĂ« njĂ« shtresĂ« e hollĂ« mbi OAuth 2.0, qĂ« shton informacione pĂ«r login-in dhe profilin e pĂ«rdoruesit qĂ« Ă«shtĂ« identifikuar. Organizimin e sesionit tĂ« login-it shpesh e quajnĂ« autentifikim [authentication], ndĂ«rsa informacioni pĂ«r pĂ«rdoruesin qĂ« ka hyrĂ« nĂ« sistem (p.sh. pĂ«r Pronari i Burimeveâin), â tĂ« dhĂ«na personale [identity]. NĂ«se Authorization Server mbĂ«shtet OIDC, herĂ« pas here quhet ofrues i tĂ« dhĂ«nave personale [identity provider], pasi ai ofron Clientâin informacion pĂ«r Pronari i BurimevenjĂ«.
OpenID Connect lejon tĂ« zbatohen skenarĂ« ku njĂ« login i vetĂ«m mund tĂ« pĂ«rdoret nĂ« shumĂ« aplikacione, â ky qasje quhet gjithashtu single sign-on (SSO). PĂ«r shembull, njĂ« aplikacion mund tĂ« mbĂ«shtesĂ« integrimin SSO me rrjetet sociale si Facebook ose Twitter, duke u lejuar pĂ«rdoruesve tĂ« pĂ«rdorin njĂ« llogari qĂ« ata tashmĂ« e kanĂ« dhe preferojnĂ« ta pĂ«rdorin.
Fluksi (flow) i OpenID Connect duket ashtu si nĂ« rastin e OAuth. Diferenca e vetme Ă«shtĂ« se nĂ« kĂ«rkesĂ«n e parĂ« pĂ«rfshihet scope-i specifik â openid, â dhe Client nĂ« fund merr si Tokenin e Aksesit, ashtu edhe ID Token.
Ashtu si nĂ« fluksin OAuth, Tokenin e Aksesit nĂ« OpenID Connect â Ă«shtĂ« njĂ« vlerĂ« e caktuar, e paqartĂ« pĂ«r Clientâin. Nga kĂ«ndvĂ«shtrimi i Clientâit Tokenin e Aksesit pĂ«rfaqĂ«son njĂ« varg tĂ« caktuar karakteresh, i cili dĂ«rgohet me çdo kĂ«rkesĂ« nĂ« Serveri Burimorâin, dhe ai pĂ«rcakton nĂ«se tokeni Ă«shtĂ« i vlefshĂ«m. ID Token pĂ«rfaqĂ«son diçka krejt ndryshe.
ID Token â Ă«shtĂ« njĂ« JWT
ID Token â Ă«shtĂ« njĂ« varg karakteresh i formatizuar nĂ« njĂ« mĂ«nyrĂ« tĂ« veçantĂ«, i njohur si JSON Web Token ose JWT (ndonjĂ«herĂ« tokenet JWT shqiptohen si «jots»). DĂ«shmitarĂ«ve tĂ« jashtĂ«m JWT mund tĂ« duket si njĂ« abuzim i paqartĂ«, megjithatĂ« Client mund tĂ« nxjerrĂ« informacione tĂ« ndryshme nga JWT, si ID, emri i pĂ«rdoruesit, koha e hyrjes nĂ« llogari, periudha e skadimit ID Tokenâa, praninĂ« e pĂ«rpjekjeve pĂ«r tĂ« ndĂ«rhyrĂ« nĂ« JWT. TĂ« dhĂ«nat brenda ID Tokenâa quhen pretendime [claims].
NĂ« rastin e OIDC, gjithashtu ekziston njĂ« mĂ«nyrĂ« standarde pĂ«r tĂ« cilĂ«n Client mund tĂ« kĂ«rkojĂ« informacion tĂ« shtuar mbi identitetin [identity] nga Serveri i Autorizimitâa, pĂ«r shembull, adresĂ«n e postĂ«s elektronike, duke pĂ«rdorur Tokenin e Aksesit.
Informacione të tjera mbi OAuth dhe OIDC
Pra, kemi kaluar shkurtimisht mbi parimet e punĂ«s sĂ« OAuth dhe OIDC. Jemi gati tĂ« thellojmĂ« mĂ« shumĂ«? Ja burime tĂ« tjera qĂ« do tâju ndihmojnĂ« tĂ« mĂ«soni mĂ« shumĂ« mbi OAuth 2.0 dhe OpenID Connect:
Si gjithmonë, mos hezitoni të komentoni. Për të qenë në diapazonin e lajmeve tona më të reja, subscriboni në dhe kompaninë Okta për zhvillues!
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
