Nota traducătorului.: În acest material remarcabil de la Okta, sunt explicate în mod clar și concis principiile de funcționare ale OAuth și OIDC (OpenID Connect). Aceste cunoștințe vor fi utile dezvoltatorilor, administratorilor de sistem și chiar „utilizatorilor obișnuiți” ai aplicațiilor web populare, care cel mai probabil schimbă și ele date confidențiale cu alte servicii.
În „epoca de piatră” a internetului, partajarea informațiilor între servicii era ușoară. Pur și simplu îi dădeai altcuiva numele tău de utilizator și parola pentru un anumit serviciu, astfel încât aceștia să se poată conecta la contul tău și să obțină orice informație de care aveau nevoie.
„Furnizați-vă contul bancar”. — „Promitem că, în ceea ce privește parola și banii, totul va fi în regulă. Promit, chiar și cu sinceritate!” *hehe*
Fioros! Nimeni și niciodată nu ar trebui să ceară utilizatorului să împărtășească numele de utilizator și parola sa, datele sale de autentificare, cu un alt serviciu. Nu există nicio garanție că organizația din spatele acestui serviciu va păstra datele în siguranță și nu va aduna mai multe informații personale decât este necesar. Poate părea absurd, dar unele aplicații folosesc încă o asemenea practică!
Astăzi există un standard unic care permite unui serviciu să utilizeze în siguranță datele altui serviciu. Din păcate, astfel de standarde folosesc o mulțime de jargon și termeni, ceea ce complică înțelegerea lor. Scopul acestui material este de a explica, cu ajutorul unor ilustrații simple, cum funcționează acestea (Credeți că desenele mele arată ca o marmeladă de copii? Ei bine, și ce dacă!).
Între timp, acest ghid este disponibil și în format video:
Doamnelor și domnilor, întâmpinați: OAuth 2.0
— este un standard de securitate care permite unei aplicații să obțină permisiunea de a accesa informații dintr-o altă aplicație. Secvența de acțiuni pentru acordarea permisiunii [permission] (sau consimțământului [consent]) este adesea numită autorizare [authorization] sau chiar autorizare delegată [delegated authorization]. Prin acest standard, permiți aplicației să acceseze datele sau să utilizeze funcțiile unei alte aplicații în numele tău, fără a-i dezvălui parola ta. Grozav!
Ca exemplu, să ne imaginăm că ai descoperit un site numit „Cea mai proastă glumă a zilei” [Terrible Pun of the Day] Și ați decis să vă înregistrați pe el pentru a primi zilnic glume proaste sub formă de mesaje text pe telefon. V-a plăcut foarte mult site-ul și ați decis să-l împărtășiți cu toți cunoscuții. La urma urmei, glumele proaste le plac tuturor, nu-i așa?
«Gluma proastă a zilei: Ați auzit despre tipul care și-a pierdut jumătatea stângă a corpului? Acum el are întotdeauna dreptate!» (traducerea este aproximativă, deoarece în original este un joc de cuvinte - nota traducătorului)
Este clar că nu este o opțiune să scrii fiecărui om din lista de contacte. Și, dacă ești măcar puțin asemănător cu mine, vei face tot posibilul pentru a evita muncă în plus. Din fericire, Terrible Pun of the Day își poate invita singur toți prietenii! Tot ce trebuie să faceți este să-i oferiți acces la adresa de e-mail a contactelor - site-ul va trimite invitații automat (OAuth e genial)!
«Toată lumea iubește glumele proaste! - Te-ai autentificat? - Vrei să deschizi accesul site-ului Terrible Pun of the Day la lista de contacte? - Mulțumesc! Acum, în fiecare zi, vom trimite memento-uri tuturor cunoscuților tăi, până la sfârșitul vremurilor! Ești cel mai bun prieten!»
- Alegeți serviciul dvs. de e-mail.
- Dacă este necesar, accesați site-ul de e-mail și conectați-vă la cont.
- Acordați permisiunea site-ului Terrible Pun of the Day de a accesa contactele.
- Întoarceți-vă pe site-ul Terrible Pun of the Day.
În cazul în care vă răzgândiți, aplicațiile care utilizează OAuth oferă, de asemenea, o modalitate de a anula accesul. Dacă decideți că nu mai doriți să partajați contactele cu Terrible Pun of the Day, puteți accesa site-ul de e-mail și să eliminați site-ul cu glume din lista aplicațiilor autorizate.
Flux OAuth
Abia am trecut prin ceea ce se numește de obicei flux [flow] OAuth. În exemplul nostru, acest flux constă din pași vizibili, precum și din câțiva pași invizibili, în cadrul cărora cele două servicii își stabilesc un acord pentru un schimb sigur de informații. În exemplul anterior cu Terrible Pun of the Day, se folosește cel mai comun flux OAuth 2.0, cunoscut sub numele de fluxul «cu cod de autorizare» [«authorization code» flow].
Înainte de a aprofunda detaliile funcționării OAuth, să discutăm despre semnificația unor termeni:
- Proprietar de Resurse:
Ești tu! Deții datele tale, credențialele tale și gestionezi toate acțiunile care pot fi efectuate cu conturile tale. - Client:
Aplicația (de exemplu, serviciul Terrible Pun of the Day) care dorește să acceseze sau să efectueze anumite acțiuni în numele Proprietar de Resursesău. - Serverul de Autorizare:
Aplicația care cunoaște Proprietar de Resursesău și unde Proprietar de Resursesău are deja un cont. - Serverul de Resurse:
Interfața de Programare a Aplicațiilor (API) sau serviciul, pe care Client dorește să-l utilizeze în numele Proprietar de Resursesău. - URI de Redirectare:
Linkul la care Serverul de Autorizare va redirecționa Proprietar de Resursesău după ce a obținut permisiunea Clientsău. Uneori este numit «URL de Înapoi» («Callback URL»). - Tipul Răspunsului:
Tipul de informație pe care îl așteaptă Client. Cea mai comună Tipul Răspunsuluisău este un cod, adică Client se așteaptă să obțină Codul de Autorizare. - Domeniul:
Aceasta este o descriere detaliată a permisiunilor necesare Clientsău, cum ar fi accesul la date sau efectuarea anumitor acțiuni. - Consimțământul:
Serverul de Autorizare cere Domeniile, solicitate Clientsău, și întreabă Proprietar de Resursesău, dacă este dispus să ofere Clientsău permisiunile corespunzătoare. - ID-ul Clientului:
Acest ID este folosit pentru a identifica Clientsău pe Serverul de Autorizaresău. - Secretul Clientului:
Aceasta este parola, care este cunoscută doar de Clientsău și Serverul de Autorizaresău. Aceasta le permite să schimbe informații într-un mod confidențial. - Codul de Autorizare:
Un cod temporar cu o perioadă scurtă de valabilitate, care Client oferă Serverul de Autorizaresău în schimb pentru Tokenul de Acces. - Tokenul de Acces:
Cheia pe care clientul o va folosi pentru a comunica cu Serverul de Resursesău. Un fel de badge sau card de acces, care oferă Clientsău permisiunea de a solicita date sau de a efectua acțiuni pe Serverul de Resursesău în numele tău.
Notă: uneori Serverul de Autorizare și Serverul de Resurse sunt același server. Totuși, în anumite cazuri, acestea pot fi servere diferite, chiar și din organizații distincte. De exemplu, Serverul de Autorizare poate fi un serviciu terț, de încredere de către Serverul de Resurse.
Acum că ne-am familiarizat cu conceptele de bază ale OAuth 2.0, să ne întoarcem la exemplul nostru și să vedem în detaliu ce se întâmplă în fluxul OAuth.
- Tu, Proprietar de Resurse, dorești să oferi serviciului Terrible Pun of the Day (Clientsău) acces la contactele tale, pentru a putea trimite invitații tuturor prietenilor tăi.
- Client redirecționează browserul către pagina Serverul de Autorizaresău și include în cerere ID-ul Clientului, URI de Redirectare, Tipul Răspunsului una sau mai multe Domeniile (permisiuni) de care are nevoie.
- Serverul de Autorizare verifică identitatea ta, solicitând, dacă este necesar, numele de utilizator și parola.
- Serverul de Autorizare afișează un formular Consimțământul (de confirmare) cu lista tuturor Domeniile, solicitate Clientsău. Accepți sau refuzi.
- Serverul de Autorizare redirecționează-te către site-ul Clientsău, folosind URI de Redirectare împreună cu Codul de Autorizare (codul de autorizare).
- Client se conectează direct la Serverul de Autorizaresău (o ocolire a browserului Proprietar de Resursesău) și trimite în siguranță ID-ul Clientului, Secretul Clientului și Codul de Autorizare.
- Serverul de Autorizare verifică datele și răspunde cu Tokenul de Acces‘token de acces).
- Acum Client poate folosi Tokenul de Acces pentru a trimite o cerere de Serverul de Resurse pentru a obține o listă de contacte.
Client ID și Secret
Cu mult înainte de a permite Terrible Pun of the Day să acceseze contactele, Clientul și Serverul de Autorizare au stabilit relații de lucru. Serverul de Autorizare a generat Client ID și Client Secret (uneori numite App ID și App Secret) și le-a trimis Clientului pentru interacțiuni ulterioare în cadrul OAuth.
«— Bună! Aș dori să lucrez cu tine! — Nicio problemă! Iată Client ID și Secretul tău!»
Numele sugerează că Client Secret ar trebui să fie păstrat secret, astfel încât să fie cunoscut doar de Client și Serverul de Autorizare. Este, de fapt, cu ajutorul acestuia că Serverul de Autorizare confirmă autenticitatea Clientului.
Dar asta nu e tot… Vă rugăm să-l salutați pe OpenID Connect!
OAuth 2.0 a fost conceput doar pentru autorizare — pentru a oferi acces la date și funcții de la o aplicație la alta. (OIDC) — este un strat subțire deasupra OAuth 2.0, adăugând informații despre conectarea și profilul utilizatorului, care s-a autentificat. Organizarea sesiunii de autentificare este adesea numită autentificare [authentication], iar informațiile despre utilizatorul autentificat (adică despre Proprietar de Resurse‘) — informații personale [identity]. Dacă Serverul de Autorizare suportă OIDC, acesta este uneori numit furnizor de informații personale [identity provider], deoarece oferă Client‘ informații despre Proprietar de Resursesău.
OpenID Connect permite implementarea scenariilor în care un singur login poate fi utilizat în mai multe aplicații — acest mod este cunoscut și sub denumirea de single sign-on (SSO). De exemplu, o aplicație poate susține integrarea SSO cu rețelele sociale, cum ar fi Facebook sau Twitter, permițând utilizatorilor să folosească contul pe care deja îl au și pe care preferă să-l utilizeze.
Fluxul (flow) OpenID Connect arată la fel ca în cazul OAuth. Singura diferență este că în cererea inițială, scope-ul specific utilizat este openid, — iar Client în cele din urmă primește ca Tokenul de Acces, sau ID Token..
Așa cum este și în fluxul OAuth, Tokenul de Acces în OpenID Connect — este o valoare care nu este clară Client‘. Din perspectiva Client‘ reprezintă un șir de caractere care este trimis împreună cu fiecare cerere către Tokenul de Acces ‘, iar acesta determină dacă tokenul este valabil. Serverul de Resursereprezintă ceva complet diferit. ID Token. ID Token este un JWT
— un șir de caractere formatat într-un mod special, cunoscut sub numele de JSON Web Token sau JWT
ID Token. (uneori token-urile JWT se pronunță „jots”). (uneori, tokenurile JWT sunt pronunțate ca „jots”)Privind din afară, JWT-ul poate părea o aberație de neînțeles, totuși Client poate extrage din JWT informații diverse, cum ar fi ID-ul, numele utilizatorului, timpul de conectare, data expirării ID Token.şi prezenţa unor încercări de manipulare a JWT-ului. Datele din interiorul ID Token.se numesc declarații [claims].
În cazul OIDC, există de asemenea un mod standard prin care Client se poate solicita informații suplimentare despre identitate [identity] de la Serverul de Autorizarede exemplu, adresa de email, folosind Tokenul de Acces.
Informații suplimentare despre OAuth și OIDC
Așadar, am discutat pe scurt despre principiile de funcționare ale OAuth și OIDC. Ești gata să aprofundezi? Iată resurse suplimentare care te vor ajuta să înveți mai multe despre OAuth 2.0 și OpenID Connect:
Ca de obicei, nu ezita să comentezi. Pentru a fi la curent cu noutățile noastre, abonează-te la și compania Okta pentru dezvoltatori!
P.S. de la traducător
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
