Shën. përk.: Në këtë material të shkëlqyer nga Okta, shpjegohet thjesht dhe qartë parimet e funksionimit të OAuth dhe OIDC (OpenID Connect). Këto njohuri do të jenë të dobishme për zhvilluesit, administratorët e sistemeve dhe madje edhe "përdoruesit e zakonshëm" të aplikacioneve të njohura në web, të cilët me siguri ndajnë gjithashtu të dhëna të ndjeshme me shërbime të tjera.
Në "epokën e gurit" të internetit, ndarja e informacionit midis shërbimeve ishte e lehtë. Ju thjesht jepnit emrin tuaj të përdoruesit dhe fjalëkalimin nga një shërbim te tjetri, që ai të hynte në llogarinë tuaj dhe të merrte çdo informacion të nevojshëm.
"Ofro fjalëkalimin tënd bankar". - "Premtojmë se do të jetë në rregull me fjalëkalimin dhe paratë. Këtu, fare sinqerisht!" *hi-hi*
Tmerr! Askush nuk duhet dhe nuk ka të drejtë të kërkojë nga përdoruesi që të ndajë emrin e tij të përdoruesit dhe fjalëkalimin, të dhënat e tij identifikuese, me një shërbim tjetër. S'ka asnjë garanci se organizata që qëndron pas këtij shërbimi do të mbajë të dhënat në siguri dhe nuk do të mbledhë më shumë informacion personal se sa është e nevojshme. Kjo mund të duket e çuditshme, por disa aplikacione ende përdorin një praktike të tillë!
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, standardet e tilla përdorin një mori fjalësh dhe terminologji që e komplikon kuptimin e tyre. Qëllimi i këtij materiali është të shpjegojë si funksionojnë ato me ilustrime të thjeshta (Mendoni se vizatimet e mia duken si gjeometri e fëmijëve? Mirë, dhe çfarë!).
Mesazhe, ky udhëzues është gjithashtu i disponueshëm në format video:
Zonja dhe zotërinj, mirëserdhët: OAuth 2.0
â Ă«shtĂ« njĂ« standard sigurie qĂ« lejon njĂ« aplikacion tĂ« marrĂ« leje pĂ«r tĂ« aksesuar informacionin nĂ« njĂ« aplikacion tjetĂ«r. Sekuenca e veprimeve pĂ«r dhĂ«nien e lejes [permission] (ose konsensit [consent]) shpesh quhet autorizim [authorization] ose madje autorizim tĂ« deleguar [delegated authorization]. Me kĂ«tĂ« standard, ju lejoni aplikacionit tĂ« lexojĂ« tĂ« dhĂ«nat ose tĂ« pĂ«rdorĂ« funksionet e njĂ« aplikacioni tjetĂ«r nĂ« emrin tuaj, pa i thĂ«nĂ« atij fjalĂ«kalimin tuaj. Klasik!
Si shembull le të imagjinojmë se keni zbuluar një faqe me emrin "Kalamari i Dështuar i Ditës" [Terrible Pun of the Day] dhe vendosët të regjistroheni, në mënyrë që të merrni çdo ditë kalamare në formën e mesazheve tekstualë në telefon. Ju e pëlqyet shumë faqen dhe vendosët ta ndani me të gjithë miqtë tuaj. Sepse shakatë e tmerrshme pëlqehen nga të gjithë, apo jo?
"Kalamari i DĂ«shtuar i DitĂ«s: Keni dĂ«gjuar pĂ«r typen qĂ« humbi pjesĂ«n e majtĂ« tĂ« trupit? Tani ai gjithmonĂ« Ă«shtĂ« i djathtĂ«!" (pĂ«rkthimi Ă«shtĂ« i pĂ«rafĂ«rt, pasi origjinali ka lojĂ« fjalĂ«sh tĂ« vetĂ«n â shĂ«n. pĂ«rkth.)
E kuptojmĂ« qĂ« tĂ« shkruash pĂ«r çdo njeri nĂ« listĂ«n e kontaktit nuk Ă«shtĂ« njĂ« opsion. Dhe, nĂ«se jeni 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Ă« vetĂ« tĂ« gjithĂ« miqtĂ« tuaj! PĂ«r kĂ«tĂ«, mjafton t'i jepni akses nĂ« emailin e kontakteve â faqja do t'i dĂ«rgojĂ« vetĂ« ftesat (OAuth udhĂ«heq)!
«TĂ« gjithĂ« e duan humorin! â A ju Ă«shtĂ« bĂ«rĂ« qasje? â Doni tĂ« lejoni aksesin e faqes Terrible Pun of the Day nĂ« listĂ«n e kontaktĂ«ve tuaj? â Faleminderit! Tani ne do t'ju dĂ«rgojmĂ« pĂ«r çdo ditĂ« kujtime pĂ«r tĂ« gjithĂ« ata qĂ« dini, deri nĂ« fund tĂ« shekujve! Ju jeni shoku mĂ« i mirĂ«!»
- Zgjidhni shërbimin tuaj të postës elektronike.
- Nëse është e nevojshme, vizitoni faqen e postës dhe hyni në llogarinë tuaj.
- Jepni leje faqes Terrible Pun of the Day për të aksesuar kontaktet.
- Kthehuni në faqen 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 se 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 kalambure nga lista e aplikacioneve të autorizuara.
Rrjedha OAuth
Së fundmi kaluam në atë që zakonisht quhet rrjedhë [flow] OAuth. Në shembullin tonë, kjo rrjedhë përbëhet nga hapa të dukshëm, si dhe disa hapa të padukshëm, në kuadër të të cilëve dy shërbime bien dakord për shkëmbimin e sigurt të informacionit. 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 thelluar në detajet e funksionimit të OAuth, le të flasim për kuptimin e disa termineve:
- Pronari i Burimeve:
Kjo jeni ju! Ju zotëroni akreditivët tuaj, të dhënat tuaja dhe menaxhoni të gjitha veprimet që mund të kryhen me llogaritë tuaja. - Klienti:
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 Burimeveâa. - Serveri i Autorizimit:
Aplikacioni qĂ« e njeh Pronari i Burimeveâa dhe nĂ« tĂ« cilin Pronari i Burimeveâa tashmĂ« ka llogari. - Serveri i Burimeve:
NjĂ« ndĂ«rfaqe pĂ«r aplikacione (API) ose shĂ«rbim, tĂ« cilin Klienti dĂ«shiron ta pĂ«rdorĂ« nĂ« emĂ«r tĂ« Pronari i Burimeveâa. - URI i Ridrejtimit:
Lidhja, nĂ« tĂ« cilĂ«n Serveri i Autorizimit do tĂ« ridrejtojĂ« Pronari i Burimeveâa pas dhĂ«nies sĂ« lejes Klientiâu. NdonjĂ«herĂ« quhet "URL i Kthimit" ("Callback URL"). - Tipi i PĂ«rgjigjes:
Lloji i informacionit qĂ« pritet tĂ« marrĂ« Klienti. MĂ« i zakonshmi Tipi i PĂ«rgjigjesâom Ă«shtĂ« kodi, qĂ« do tĂ« thotĂ« Klienti pĂ«r tĂ« cilin pritet tĂ« marrĂ« Kodi i Autorizimit. - Shkalla:
Ky Ă«shtĂ« njĂ« pĂ«rshkrim i detajuar i lejeve qĂ« kĂ«rkohen Klientiâu, si akses nĂ« tĂ« dhĂ«na ose kryerja e veprimeve tĂ« caktuara. - PĂ«lqimi:
Serveri i Autorizimit merr Skopet, tĂ« kĂ«rkuara Klientiâom, dhe pyet Pronari i Burimeveâa, nĂ«se Ă«shtĂ« gati tĂ« ofrojĂ« Klientiâu lejet pĂ«rkatĂ«se. - Identifikuesi i Klientit:
Ky ID pĂ«rdoret pĂ«r identifikimin Klientiâas nĂ« Serveri i Autorizimitâe. - Klienti Sekret:
Ky Ă«shtĂ« njĂ« fjalĂ«kalim qĂ« Ă«shtĂ« i njohur vetĂ«m nga Klientiâu dhe Serveri i Autorizimitâu. Ai u lejon atyre tĂ« shkĂ«mbejnĂ« informacione nĂ« mĂ«nyrĂ« konfidenciale. - Kodi i Autorizimit:
NjĂ« kod pĂ«rkohĂ«sor me njĂ« periudhĂ« tĂ« vogĂ«l tĂ« vlefshmĂ«risĂ«, i cili Klienti siguron Serveri i Autorizimitâu nĂ« shkĂ«mbim tĂ« Tokenit tĂ« Qasjes. - Tokenit tĂ« Qasjes:
NjĂ« çelĂ«s qĂ« klienti do tĂ« pĂ«rdorĂ« pĂ«r t'u lidhur me Serveri i Burimeveân. NjĂ« badge ose çelĂ«s-karta qĂ« i jep Klientiâu leje pĂ«r tĂ« kĂ«rkuar tĂ« dhĂ«na ose pĂ«r tĂ« realizuar veprime nĂ« Serveri i Burimeveâa nĂ« emrin tuaj.
Shënim: herë pas here, Serveri i Autorizimit dhe Serveri Burimor janë njëjtë. Megjithatë, në disa raste, këto mund të jenë servera të ndryshëm, madje edhe të pakësuar në të njëjtën organizatë. Për shembull, Serveri i Autorizimit mund të jetë një shërbim i palës së tretë, të cilit i beson Serveri Burimor.
Tani që jemi njohur me konceptet bazë të OAuth 2.0, le të kthehemi te shembulli ynë dhe të shqyrtojmë me detaje atë që ndodh në rrymën OAuth.
- Ju, Pronari i Burimeve, dĂ«shironi t'i jepni shĂ«rbimit Terrible Pun of the Day (Klientiâu) qasje nĂ« kontaktet tuaja, nĂ« mĂ«nyrĂ« qĂ« ai tĂ« mund tĂ« dĂ«rgojĂ« ftesa tĂ« gjithĂ« miqve tuaj.
- Klienti kthen shfletuesin nĂ« faqen Serveri i Autorizimitân dhe pĂ«rfshin nĂ« kĂ«rkesĂ« Identifikuesi i Klientit, URI i Ridrejtimit, Tipi i PĂ«rgjigjes dhe njĂ« ose mĂ« shumĂ« Skopet (leje) qĂ« i nevojiten atij.
- Serveri i Autorizimit kontrollon ju, duke kërkuar emrin e përdoruesit dhe fjalëkalimin në rast nevoje.
- Serveri i Autorizimit shfaq formularin PĂ«lqimi (konfirmimi) me njĂ« listĂ« tĂ« tĂ« gjitha Skopet, tĂ« kĂ«rkuara Klientinga âa. Ju pranoni ose refuzoni.
- Serveri i Autorizimit ju ridrejton nĂ« faqen e Klientiâs, duke pĂ«rdorur URI i Ridrejtimit nĂ« bashkĂ«punim me Kodi i Autorizimit (kodin e autorizimit).
- Klienti lidhet drejtpĂ«rdrejt me Serveri i Autorizimitâin (duke pĂ«rshkuar shfletuesin Pronari i Burimeveâ tĂ«) Identifikuesi i Klientit, Klienti Sekret dhe Kodi i Autorizimit.
- Serveri i Autorizimit dhe dërgon në siguri Tokenit të Qasjeskontrollon të dhënat dhe përgjigjet me
- Tani Klienti âin (tokenin e aksesit). Tokenit tĂ« Qasjes mund tĂ« pĂ«rdorĂ« Serveri i Burimeve pĂ«r tĂ« dĂ«rguar njĂ« kĂ«rkesĂ« pĂ«r
me qellim që të marrë listën e kontakteve.
Client ID dhe Secret Më parë se të lejonit Terrible Pun of the Day të kishte qasje në kontaktet, Client dhe Authorization Server ishin vendosur marrëdhënie funksionale. Authorization Server krijoi Client ID dhe Client Secret (ndonjëherë i quajnë dhe App IDApp Secret
) dhe ia dĂ«rgoi Clientâit pĂ«r ndĂ«rveprim tĂ« mĂ«tejshĂ«m brenda OAuth.
«â Tung! Doja tĂ« punoj me ty! â AsnjĂ« problem! KĂ«tu janĂ« Client ID dhe Secret!»
Emri tregon se Client Secret duhet tĂ« mbahet sekret, qĂ« tĂ« dihet vetĂ«m nga Client dhe Authorization Server. Sepse me ndihmĂ«n e tij, Authorization Server verifikon vĂ«rtetĂ«sinĂ« e Clientâit.
Por kjo nuk Ă«shtĂ« gjithçka⊠Ju lutem, mirĂ«pritni OpenID Connect! OAuth 2.0 Ă«shtĂ« zhvilluar vetĂ«m pĂ«r autorizimin. (OIDC) Ă«shtĂ« njĂ« shtresĂ« e hollĂ« mbi OAuth 2.0, e cila shton informacion mbi hyrjen dhe profilin e pĂ«rdoruesit qĂ« ka hyrĂ« nĂ« llogari. Organizimi i seancĂ«s sĂ« hyrjes shpesh quhet autentifikim [authentication], dhe informacioni pĂ«r pĂ«rdoruesin e autentifikuar (p.sh. pĂ«r Pronari i Burimeveâe), tĂ« dhĂ«na personale [identity]. NĂ«se Servieri i Autorizimit mbĂ«shtet OIDC, ndonjĂ«herĂ« quhet ofrues i tĂ« dhĂ«nave personale [identity provider], pasi ai ofron Klientiâu informacionin mbi Pronari i Burimeveâe.
OpenID Connect lejon realizimin e skenarĂ«ve ku njĂ« hyrje e vetme mund tĂ« pĂ«rdoret nĂ« shumĂ« aplikacione, â ky qasje njihet gjithashtu si single sign-on (SSO). PĂ«r shembull, njĂ« aplikacion mund tĂ« mbĂ«shtesĂ« integrimin SSO me rrjete sociale, si Facebook ose Twitter, duke lejuar pĂ«rdoruesit tĂ« pĂ«rdorin llogarinĂ« qĂ« ata tashmĂ« e kanĂ« dhe e preferojnĂ«.
Flow-i (procĂ«si) OpenID Connect duket ashtu siç Ă«shtĂ« nĂ« rastin e OAuth. Diferenca e vetme Ă«shtĂ« se nĂ« kĂ«rkesĂ«n fillestare, scope-i specifik i pĂ«rdorur Ă«shtĂ« openid, â dhe Klienti nĂ« fund merr si Tokenit tĂ« Qasjes, ashtu edhe ID Token.
Po ashtu, si nĂ« procesin e OAuth, Tokenit tĂ« Qasjes nĂ« OpenID Connect â kjo Ă«shtĂ« njĂ« vlerĂ« e caktuar qĂ« Ă«shtĂ« e paqartĂ«. Klientiâu. Nga kĂ«ndvĂ«shtrimi Klientiâa Tokenit tĂ« Qasjes pĂ«rfaqĂ«son njĂ« varg simboresh qĂ« dĂ«rgohet me çdo kĂ«rkesĂ« drejt Serveri i Burimeveâu, dhe ai pĂ«rcakton nĂ«se tokeni Ă«shtĂ« i vlefshĂ«m. ID Token pĂ«rfaqĂ«son diçka krejt tjetĂ«r.
ID Token â Ă«shtĂ« njĂ« JWT
ID Token â Ă«shtĂ« njĂ« varg simboresh i formatizuar nĂ« njĂ« mĂ«nyrĂ« tĂ« veçantĂ«, i njohur si JSON Web Token ose JWT (ndonjĂ«herĂ« tokenet JWT shqiptohen si «jots»). VĂ«shtruesit e jashtĂ«m mund tĂ« mendojnĂ« se JWT Ă«shtĂ« njĂ« gjuhĂ« e çuditshme, megjithatĂ« Klienti mund tĂ« nxjerrĂ« informacione tĂ« ndryshme nga JWT, tĂ« tilla si ID, emri i pĂ«rdoruesit, koha e hyrjes nĂ« llogari, skadimi ID Tokenâa, dhe pĂ«rpjekjet pĂ«r ndĂ«rhyrje nĂ« JWT. TĂ« dhĂ«nat brenda ID Tokenâa quhen kĂ«rkesat [claims].
NĂ« rastin e OIDC ka gjithashtu njĂ« mĂ«nyrĂ« standarde me anĂ« tĂ« sĂ« cilĂ«s Klienti mund tĂ« kĂ«rkojĂ« informacione shtesĂ« mbi identitetin [identity] nga Serveri i Autorizimitâa, pĂ«r shembull, adresĂ«n e emailit, duke pĂ«rdorur Tokenit tĂ« Qasjes.
Më shumë informacione mbi OAuth dhe OIDC
Pra, kemi shqyrtuar shkurtimisht parimet e funksionimit të OAuth dhe OIDC. A je gati të thellohesh më shumë? Ja disa burime shtesë që do të ndihmojnë për të mësuar më shumë rreth OAuth 2.0 dhe OpenID Connect:
Si zakonisht, mos hezitoni të komentoni. Për t'u mbajtur të informuar mbi novitetet tona, regjistrohuni te dhe kompania Okta për zhvilluesit!
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
