Ce este OAuth? „Conectează-te cu Google” și accesul delegat, explicate

OAuth este un standard deschis care permite unui utilizator să acorde unei aplicații acces limitat la contul său de pe alt serviciu, fără să îi dea parola. Când apeși „Connect Google Calendar” și vezi un ecran care întreabă „Permiți acestei aplicații să vadă evenimentele tale?”, asta este OAuth. Aplicația primește un token doar pentru ce ai aprobat, pe care îl poți revoca oricând. Același mecanism, cu un strat suplimentar numit OpenID Connect, stă în spatele „Conectează-te cu Google” și al butoanelor similare.

De ce contează OAuth când construiești cu AI

OAuth apare în două situații frecvente când construiești o aplicație:

1. Autentificare socială. Vrei ca utilizatorii tăi să se conecteze cu „Sign in with Google” (sau Apple, Microsoft, GitHub) în loc să creeze o altă parolă. Vezi cum adaugi autentificare în aplicația ta.
2. Conectarea la conturile utilizatorilor de pe alte servicii. Aplicația ta trebuie să citească calendarul unui utilizator, să posteze pe contul lui de social media, să preia fișiere din spațiul lui cloud sau să sincronizeze datele lui de contabilitate.

În ambele cazuri, constructorul tău cu AI poate scrie codul, dar unii pași îi poți face doar tu: crearea unei aplicații de dezvoltator la furnizor, obținerea unui client ID și a unui client secret, înregistrarea adreselor de callback și, pentru unele permisiuni, trecerea prin revizuirea furnizorului. Dacă înțelegi cum funcționează OAuth, acești pași — și erorile pe care le produc — devin mult mai puțin misterioși. Pentru imaginea de ansamblu a autentificării, vezi ce este autentificarea.

O analogie din viața de zi cu zi

Gândește-te la un card de cameră de hotel. La check-in, recepția confirmă cine ești, apoi îți dă un card care deschide camera ta și sala de sport — nu celelalte camere, nu zonele personalului — și care nu mai funcționează la check-out. Cardul nu conține pașaportul tău. Dacă îl pierzi, recepția îl anulează și îți emite unul nou.

• Recepția este serverul de autorizare (pagina de autentificare Google).
• Verificarea identității tale este autentificarea ta în Google.
• Cardul este tokenul de acces.
• „Doar camera și sala de sport” sunt scope-urile pe care le-ai aprobat.
• Check-out-ul este expirarea tokenului sau revocarea accesului de către tine.

Aplicația pe care o folosești nu îți vede niciodată parola Google, doar cardul.

Cum funcționează OAuth, pas cu pas

Cel mai frecvent flux pentru aplicațiile web este authorization code flow. Iată ce se întâmplă când un utilizator își conectează Google Calendar la o aplicație de programări:

1. Click. Utilizatorul apasă „Connect Google Calendar”.
2. Redirecționare către furnizor. Aplicația trimite browserul către Google cu ID-ul ei de client, scope-urile pe care le cere (citirea evenimentelor din calendar) și redirect URI, adresa la care Google să trimită utilizatorul înapoi.
3. Autentificare și consimțământ. Utilizatorul se autentifică în Google (dacă nu este deja) și vede un ecran de consimțământ cu lista a ceea ce cere aplicația. Apasă Allow.
4. Înapoi cu un cod. Google redirecționează browserul către redirect URI-ul aplicației, cu un cod de autorizare scurt, de unică folosință.
5. Schimbul pe server. Serverul aplicației trimite acel cod, împreună cu client secret-ul, direct către Google și primește un token de acces (și adesea un token de reîmprospătare).
6. Folosirea API-ului. Serverul apelează API-ul Google Calendar cu tokenul de acces și obține evenimentele utilizatorului.

Callback-ul de la pasul 4 arată cam așa:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

Iar răspunsul cu token de la pasul 5 este JSON, cam așa:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

Punctul important de design: schimbul de token are loc între server și server, deci client secret-ul și token-urile nu trebuie să treacă vreodată prin browser.

OAuth vs OpenID Connect vs propria ta autentificare

Multe aplicații le combină: autentificare cu email și parolă, plus „Sign in with Google” prin OIDC, plus conexiuni OAuth separate către alte servicii.

Termeni cheie

Concepții greșite frecvente

• „OAuth este un sistem de autentificare.” OAuth simplu acordă acces; OpenID Connect se ocupă de identitate. Folosirea unui simplu token de acces ca dovadă a identității cuiva a provocat erori reale de securitate.
• „Aplicația primește parola mea.” Nu o primește niciodată. Acesta este scopul.
• „Cererea de mai multe scope-uri este inofensivă.” Utilizatorii sunt mai precauți cu cererile largi, iar furnizori precum Google pot cere o revizuire a aplicației pentru scope-urile sensibile sau restricționate. Cere doar ce ai nevoie.
• „Client secret-ul poate sta în frontend.” Orice este în codul din browser este public. Ține-l în secretele de pe server.
• „Funcționează în testare, deci va funcționa în producție.” Furnizorii limitează adesea aplicațiile neverificate — de exemplu, la utilizatori de test enumerați — iar adresa de redirecționare pentru domeniul tău live trebuie înregistrată separat.
• „Tokenurile durează pentru totdeauna.” Tokenurile de acces expiră repede, iar utilizatorii pot revoca accesul. Aplicația ta trebuie să gestioneze ambele situații cu grație.

Ce să ceri constructorului tău cu AI

• „Adaugă «Sign in with Google» folosind OpenID Connect cu o bibliotecă de autentificare bine întreținută — nu scrie fluxul OAuth de mână.”
• „Folosește fluxul authorization code cu PKCE și verifică parametrul state.”
• „Citește client ID-ul și client secret-ul din variabile de mediu, pe server.”
• „Cere doar scope-urile de care avem nevoie: acces de citire la calendar.”
• „Spune-mi toate adresele de redirecționare pe care trebuie să le înregistrez în consola furnizorului, pentru previzualizare, pentru URL-ul publicat și pentru domeniul meu personalizat.”
• „Stochează tokenurile de reîmprospătare criptat în baza de date și, pentru tokenurile expirate sau revocate, cere utilizatorului să se reconecteze.”
• „Lasă utilizatorii să deconecteze integrarea din pagina lor de setări.”

OAuth și Mythex

Mythex nu are autentificare integrată pentru utilizatorii finali ai aplicațiilor pe care le construiești; documentația sa descrie o abordare cu propriul furnizor — alegi o bibliotecă de autentificare sau un furnizor găzduit, îi salvezi cheile ca secrete ale proiectului, iar agentul scrie codul. Rețeta de adăugare a autentificării are un prompt de start pentru asta. Vei întâlni OAuth și în Mythex însuși: te poți înscrie cu Google, conectarea GitHub pentru sincronizarea depozitului folosește OAuth GitHub, iar asistenții AI care se conectează la Mythex prin MCP trec printr-o pagină de consimțământ OAuth. Pentru mai multe, vezi ce este autentificarea și ce este autentificarea în doi pași.

Întrebări