Ce este autentificarea? Autentificări, sesiuni și OAuth explicate

Autentificarea este modul prin care o aplicație confirmă cine este un utilizator — de obicei verificând ceva ce știe (o parolă), ceva ce are (un cod trimis pe telefon sau pe e-mail) sau o identitate de la un serviciu de încredere (cum ar fi „Sign in with Google”). Odată ce utilizatorul este autentificat, aplicația îl ține minte cu o sesiune sau un token, ca să nu se logheze la fiecare pagină. Decizia privind ce are voie să facă acel utilizator cunoscut este un pas separat, numit autorizare.

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

Adăugarea unui login este una dintre cele mai frecvente cereri făcute unui constructor de aplicații cu AI și una dintre cele mai ușor de greșit subtil. O pagină de login este simplu de generat. Partea grea este tot ce o înconjoară:

• Sunt parolele stocate în siguranță?
• Verifică fiecare pagină privată și fiecare endpoint API cine întreabă?
• Poate un client logat să vadă datele altui client schimbând un număr din URL?
• Ce se întâmplă când cineva își uită parola?

O aplicație poate arăta perfect sigură și să eșueze la toate acestea. Înțelegerea componentelor îți permite să pui întrebările potrivite și să testezi lucrurile potrivite.

O analogie din viața de zi cu zi

Gândește-te la cazarea într-un hotel.

La recepție arăți actul de identitate. Asta este autentificarea: dovedești cine ești. Recepționera îți dă apoi un card de acces. Acel card este sesiunea ta: pe durata șederii nu mai arăți actul de identitate; doar atingi cardul.

Cardul deschide camera ta, sala de sport și liftul până la etajul tău — dar nu camerele altor oameni sau biroul personalului. Asta este autorizarea: la ce resurse are acces identitatea ta. Dacă pierzi cardul, hotelul îl poate dezactiva la recepție (revocarea sesiunii). Când pleci, nu mai funcționează (delogare sau expirare).

„Sign in with Google” este ca un hotel care acceptă o scrisoare de la un partener de încredere care spune „aceasta este persoana” în loc să-ți verifice singur actul de identitate.

Metodele principale de login

Cum trebuie stocate parolele

O aplicație sigură nu stochează niciodată parola ta reală. Stochează un hash: rezultatul unei funcții unidirecționale care transformă parola într-un șir fix. Când te loghezi, aplicația face hash la ce ai scris și compară rezultatul cu hash-ul stocat.

Două detalii fac asta sigur:

• O sare (salt) — o valoare aleatorie adăugată fiecărei parole înainte de hash, astfel că două persoane cu aceeași parolă au hash-uri diferite, iar tabelele de căutare precalculate devin inutile.
• Un algoritm lent, creat pentru parole — precum Argon2, bcrypt sau scrypt. Hash-urile de uz general precum MD5 sau SHA-256 sunt prea rapide de una singură; atacatorii pot încerca miliarde de ghiciri.

Hash-ul nu este același lucru cu criptarea. Datele criptate pot fi decriptate cu o cheie; un hash de parolă este proiectat să nu fie reversibil deloc.

Sesiuni vs tokenuri

După login, aplicația trebuie să te recunoască la fiecare cerere. Există două abordări comune.

Pentru cookie-uri, trei setări contează: HttpOnly (JavaScript din pagină nu poate citi cookie-ul), Secure (trimis doar prin HTTPS) și SameSite (limitează trimiterea lui din cereri venite de la alte site-uri). Stocarea tokenurilor în localStorage al browserului este frecventă, dar le expune oricărui script care rulează pe pagină.

OAuth și „Sign in with Google”

OAuth 2.0 este un standard pentru autorizare delegată: permite unei aplicații să obțină acces limitat la contul tău de pe alt serviciu — de exemplu, să citească Google Calendar-ul tău — fără să vadă vreodată parola ta Google. Ești trimis la Google, aprobi permisiuni specifice (numite scopes), iar Google îi dă aplicației un token doar pentru acele permisiuni.

OAuth, singur, a fost proiectat să acorde acces, nu să spună cine ești. OpenID Connect (OIDC) este un strat peste OAuth 2.0 care adaugă identitate, și asta folosește „Sign in with Google” sau „Sign in with Apple”. Pentru configurare, îți înregistrezi aplicația la furnizor și primești un client ID și un client secret; secretul rămâne pe serverul tău.

Un exemplu practic: login pentru un portal de clienți

Să presupunem că construiești un portal în care clienții unei agenții de design își văd proiectele și facturile.

• Autentificare: clienții se loghează cu e-mail și link magic, deci nu există parole de gestionat. Angajații agenției se loghează cu conturi Google Workspace.
• Roluri: fiecare utilizator are un rol — client sau staff.
• Reguli de autorizare:

• Unde se aplică: pe server, pentru fiecare cerere. Serverul caută utilizatorul logat și returnează doar proiectele unde project.company_id se potrivește cu compania utilizatorului. Ascunderea butonului „Marchează plătită” nu este suficientă — endpoint-ul în sine trebuie să refuze.

Termeni explicați

Greșeli și concepții greșite frecvente

• Verificarea permisiunilor doar în pagină. Dacă browserul ascunde un buton, dar API-ul nu verifică, oricine poate apela API-ul direct.
• Încrederea în ID-urile din URL. /invoices/1042 trebuie să verifice că factura 1042 aparține utilizatorului logat.
• Inventarea propriei criptografii. Folosește biblioteci bine cunoscute sau furnizori; nu lăsa AI-ul să inventeze o schemă de hash.
• Resetare slabă a parolei. Linkurile de resetare ar trebui să fie de unică folosință, să expire repede și să nu dezvăluie dacă un e-mail are cont.
• Confundarea login-ului tău cu cel al constructorului. Utilizatorii aplicației tale sunt separați de contul tău din instrumentul cu care construiești.
• Lipsa limitării încercărilor de login. Fără ea, atacatorii pot încerca parole la nesfârșit.

Ce să ceri constructorului tău de aplicații cu AI

• „Adaugă înregistrare și login folosind [o bibliotecă sau un furnizor bine cunoscut]. Nu scrie hashing de parole personalizat.”
• „Stochează parolele hash-uite cu bcrypt sau Argon2.”
• „Folosește cookie-uri HttpOnly, Secure pentru sesiune.”
• „Adaugă roluri: admin și member. Listează fiecare endpoint și ce roluri îl pot apela.”
• „Asigură-te pe server că utilizatorii pot citi și edita doar propriile înregistrări. Apoi arată-mi cum ai verificat.”
• „Adaugă resetarea parolei cu linkuri de unică folosință care expiră într-o oră.”
• „Limitează rata încercărilor de login.”

Apoi testează singur: creează două conturi și încearcă să ajungi la datele unuia cât ești logat ca celălalt. Ghidul nostru pentru adăugarea login-ului și lista de verificare a securității merg mai departe.

Autentificarea în Mythex

Mythex nu oferă un produs de autentificare integrat pentru utilizatorii aplicației tale; tu alegi o abordare — e-mail și parolă stocate în baza de date a proiectului tău sau SDK-ul unui furnizor găzduit — și ceri agentului să o adauge. Cheile furnizorului merg în secretele proiectului, nu în chat. Asta este separat de modul în care te loghezi în Mythex însuți. Rețeta din documentație despre adăugarea login-ului în aplicația ta are un prompt de start pe care îl poți adapta, iar ce este un API explică unde trăiesc verificările de pe server.

Întrebări