Notă. transl.: Acest articol grozav al lui Okta explică cum funcționează OAuth și OIDC (OpenID Connect) într-un mod simplu și clar. 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 date confidențiale cu alte servicii.
În epoca de piatră a internetului, schimbul de informații între servicii era ușor. Pur și simplu ți-ai dat login-ul și parola de la un serviciu la altul, astfel încât el a intrat în contul tău și a primit orice informație de care avea nevoie.
— Dă-mi contul tău bancar. „Promitem că totul va fi bine cu parola și banii. Asta e sincer, sincer!" *hee hee*
Groază! Nimeni nu ar trebui să ceară unui utilizator să partajeze un nume de utilizator și o parolă, acreditările, cu alt serviciu. Nu există nicio garanție că organizația din spatele acestui serviciu va păstra datele în siguranță și nu va colecta mai multe informații personale decât este necesar. Poate suna nebunesc, dar unele aplicații încă folosesc această practică!
Astăzi există un singur standard care permite unui serviciu să utilizeze în siguranță datele altuia. Din păcate, astfel de standarde folosesc mult jargon și termeni, ceea ce le complică înțelegerea. Scopul acestui material este de a explica modul în care funcționează folosind ilustrații simple (credeți că desenele mele seamănă cu împingerea copiilor? Ei bine!).
Apropo, acest ghid este disponibil și în format video:
Doamnelor și domnilor, bine ați venit: 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 pașilor pentru eliberarea autorizației [permisiune] (Sau, consimţământ [consimţământ]) sună adesea autorizare [autorizare] sau autorizatie delegata [autorizare delegată]. Cu acest standard, permiteți unei aplicații să citească date sau să utilizeze funcțiile unei alte aplicații în numele dvs. fără a-i oferi parola. Clasă!
De exemplu, să presupunem că descoperiți un site numit „Lucky Pun of the Day” [Tribul joc de cuvinte al zilei] și a decis să se înregistreze pe ea pentru a primi zilnic jocuri de cuvinte sub formă de mesaje text la telefon. Ți-a plăcut foarte mult site-ul și ai decis să-l distribui tuturor prietenilor tăi. La urma urmei, tuturor le plac jocurile de cuvinte înfiorătoare, nu?
„Nefericitul joc de cuvinte al zilei: ai auzit despre tipul care și-a pierdut jumătatea stângă a corpului? Acum are întotdeauna dreptate!” (traducere aproximativă, deoarece originalul are propriul joc de cuvinte - aprox. traducere)
Este clar că a scrie fiecărei persoane din lista de contacte nu este o opțiune. Și, dacă sunteți chiar puțin ca mine, atunci veți face orice pentru a evita munca inutilă. Din fericire, Terrible Pun of the Day vă poate invita toți prietenii de la sine! Pentru a face acest lucru, trebuie doar să deschideți accesul la e-mailul persoanelor de contact - site-ul însuși le va trimite invitații (reguli OAuth)!
„Toată lumea iubește jocurile de cuvinte! - Deja logat? „Ați dori să permiteți site-ului web Terrible Pun of the Day să vă acceseze lista de contacte? - Mulțumesc! De acum înainte, vom trimite mementouri în fiecare zi tuturor celor pe care îi cunoști, până la sfârșitul timpului! Esti 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 contul dvs.
- Acordați permisiunea Terrible Pun of the Day pentru a vă 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ă și o modalitate de a revoca accesul. Odată ce decideți că nu mai doriți să partajați contacte cu Terrible Pun of the Day, puteți accesa site-ul de e-mail și puteți elimina site-ul joc de cuvinte din lista de aplicații autorizate.
Flux OAuth
Tocmai am trecut prin ceea ce se numește de obicei curgere [curgere] OAuth. În exemplul nostru, acest flux constă din pași vizibili, precum și mai mulți pași invizibili, în care două servicii convin asupra unui schimb securizat de informații. Exemplul anterior Terrible Pun of the Day folosește cel mai comun flux OAuth 2.0, cunoscut sub numele de flux „cod de autorizare”. [flux „cod de autorizare”].
Înainte de a ne aprofunda în detaliile modului în care funcționează OAuth, să vorbim despre semnificația unor termeni:
- Proprietarul resurselor:
Esti tu! Vă dețineți acreditările, datele și controlați toate activitățile care pot fi efectuate în conturile dvs. - Client:
O aplicație (de exemplu, serviciul Terrible Pun of the Day) care dorește să acceseze sau să efectueze anumite acțiuni în numele Proprietarul resurselor'а. - Server de autorizare:
Aplicația care știe Proprietarul resurselor'a si in care u Proprietarul resurselorai deja un cont. - server de resurse:
Interfață de programare a aplicațiilor (API) sau serviciu care Client dorește să folosească în numele Proprietarul resurselor'а. - URI de redirecționare:
Link-ul care Server de autorizare va redirecționa Proprietarul resurselor'și după acordarea permisiunii Client'la. Este uneori denumită „Adresa URL de apel invers”. - tipul de răspuns:
Tipul de informații care se preconizează a fi primite Client. Cel mai comun tipul de răspuns„Ohm este codul, adică Client se asteapta sa primeasca Cod de autorizare. - domeniu:
Aceasta este o descriere detaliată a permisiunilor necesare Client'y, cum ar fi accesarea datelor sau efectuarea anumitor acțiuni. - De acord!:
Server de autorizare beretă Scopessolicitat Client'om, şi întreabă Proprietarul resurselor'a, este gata să ofere Client'au permisiunile corespunzătoare. - ID-ul clientului:
Acest ID este folosit pentru a identifica Client'a on Server de autorizare'e. - Secretul clientului:
Aceasta este o parolă care este cunoscută doar Client'tu și Server de autorizare'la. Le permite să partajeze informații în mod privat. - Cod de autorizare:
Cod temporar cu o perioadă scurtă de valabilitate, care Client furnizează Server de autorizare'y in schimbul Jeton de acces. - Jeton de acces:
Cheia cu care clientul o va folosi pentru a comunica server de resurse'om. Un fel de insignă sau card-cheie care oferă Client„au permisiunea de a solicita date sau de a efectua acțiuni asupra server de resurseE în numele tău.
Nota: Uneori, serverul de autorizare și serverul de resurse sunt același server. Cu toate acestea, în unele cazuri, acestea pot fi servere diferite, chiar dacă nu aparțin aceleiași organizații. De exemplu, serverul de autorizare poate fi un serviciu terță parte de încredere de către serverul de resurse.
Acum că am acoperit conceptele de bază ale OAuth 2.0, să ne întoarcem la exemplul nostru și să aruncăm o privire mai atentă la ceea ce se întâmplă în fluxul OAuth.
- Tu, Proprietarul resurselor, doriți să furnizați serviciul Terrible Pun of the Day (Clienty) acces la contactele tale, astfel încât acestea să poată trimite invitații tuturor prietenilor tăi.
- Client redirecționează browserul către pagină Server de autorizare'a și includeți în interogare ID-ul clientului, URI de redirecționare, tipul de răspuns și una sau mai multe Scopes (permisiuni) de care are nevoie.
- Server de autorizare vă verifică, cerând un nume de utilizator și o parolă dacă este necesar.
- Server de autorizare afișează un formular De acord! (confirmări) cu o listă a tuturor Scopessolicitat Client'om. Sunteți de acord sau refuzați.
- Server de autorizare te redirecționează către site Client'a, folosind URI de redirecționare cu Cod de autorizare (Cod de autorizare).
- Client comunică direct cu Server de autorizare'ohm (ocolind browserul Proprietarul resurselor'a) și trimite în siguranță ID-ul clientului, Secretul clientului и Cod de autorizare.
- Server de autorizare verifică datele și răspunde cu Jeton de acces'om (jeton de acces).
- acum Client poate utiliza Jeton de acces pentru a trimite o cerere către server de resurse pentru a obține o listă de contacte.
ID client și secret
Cu mult înainte de a permite Terrible Pun of the Day să vă acceseze contactele, clientul și serverul de autorizare stabiliseră o relație de lucru. Serverul de autorizare a generat ID-ul clientului și Secretul clientului (uneori numit ID-ul aplicației и Secretul aplicației) și le-a trimis Clientului pentru interacțiune ulterioară în cadrul OAuth.
"- Buna ziua! Aș dori să lucrez cu tine! - Sigur, nu este o problemă! Iată ID-ul și secretul tău de client!”
Numele implică faptul că Secretul Clientului trebuie păstrat secret, astfel încât numai Clientul și Serverul de Autorizare să-l cunoască. La urma urmei, cu ajutorul lui Serverul de autorizare confirmă adevărul Clientului.
Dar asta nu este tot... Vă rugăm să bun venit OpenID Connect!
OAuth 2.0 este conceput numai 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 care adaugă detaliile de conectare și de profil ale utilizatorului care este conectat la cont. Organizarea unei sesiuni de conectare este adesea denumită autentificare [autentificare]și informații despre utilizatorul conectat la sistem (de exemplu, despre Proprietarul resurselor'e), - date personale [identitate]. Dacă serverul de autorizare acceptă OIDC, uneori se numește furnizor de date cu caracter personal [furnizor de identitate]deoarece oferă Client'au informații despre Proprietarul resurselor'e.
OpenID Connect vă permite să implementați scenarii în care o singură autentificare poate fi utilizată în mai multe aplicații - această abordare este cunoscută și ca o singură logare (SSO). De exemplu, o aplicație poate sprijini integrarea SSO cu rețele sociale precum Facebook sau Twitter, permițând utilizatorilor să folosească un cont pe care îl au deja și preferă să îl folosească.
Fluxul (fluxul) OpenID Connect arată la fel ca în cazul OAuth. Singura diferență este că, în cererea primară, domeniul specific utilizat este openid, - A Client în cele din urmă devine ca Jeton de accesȘi Token de identificare.
La fel ca în fluxul OAuth, Jeton de acces în OpenID Connect, aceasta este o valoare care nu este clară Client'la. Din punct de vedere Client'а Jeton de acces reprezintă un șir de caractere care este transmis împreună cu fiecare cerere către server de resurse'y, care determină dacă simbolul este valid. Token de identificare reprezintă cu totul altceva.
ID Token este un JWT
Token de identificare este un șir de caractere special formatat, cunoscut sub numele de JSON Web Token sau JWT (uneori jetoanele JWT sunt pronunțate ca „jote”). Pentru observatorii din afară, JWT poate părea o farfurie de neînțeles, dar Client poate extrage diverse informații din JWT, cum ar fi ID, nume de utilizator, ora de conectare, data de expirare Token de identificare„a, prezența încercărilor de a interfera cu JWT. Date din interior Token de identificare'a sunt numite aplicatii [creanțe].
În cazul OIDC, există și o modalitate standard prin care Client poate solicita informații suplimentare despre individ [identitate] din Server de autorizare'o, de exemplu, o adresă de e-mail folosind Jeton de acces.
Aflați mai multe despre OAuth și OIDC
Așadar, am analizat pe scurt modul în care funcționează OAuth și OIDC. Ești gata să sapi mai adânc? Iată resurse suplimentare pentru a vă ajuta să aflați mai multe despre OAuth 2.0 și OpenID Connect:
Ca întotdeauna, nu ezitați să comentați. Pentru a fi la curent cu ultimele noastre știri, abonați-vă la и Okta pentru dezvoltatori!
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com