Cum adaugi autentificare în aplicația ta: parole, linkuri magice, Google și roluri

Pentru a adăuga login într-o aplicație, alege o metodă — e-mail și parolă, linkuri magice (un link de autentificare de unică folosință trimis pe e-mail) sau „Sign in with Google” — și implementeaz-o cu o bibliotecă de autentificare verificată sau cu un furnizor găzduit, nu de la zero. Apoi decide ce are voie să facă fiecare tip de utilizator (roluri) și impune asta pe server, pentru fiecare pagină și cerere API. Sesiunile ar trebui să folosească cookie-uri sigure, să expire și să se încheie corect la deconectare.

Acest ghid parcurge fiecare alegere și detaliile care deosebesc un login funcțional de unul sigur. Pentru conceptele din spatele lui, vezi ce este autentificarea.

Decide mai întâi: ai nevoie de login deloc?

Login-ul adaugă fricțiune și responsabilitate. Ai nevoie de el când:

• Utilizatorii au date private (rezervările, documentele, facturile lor)
• Utilizatorii pot modifica lucruri pe care le vor vedea alții
• Ceri bani pentru acces
• Persoane diferite au nevoie de permisiuni diferite (proprietar, angajat, client)

Este posibil să nu ai nevoie de el pentru un site de marketing, un director public sau un formular care îți trimite doar un e-mail. O listă de așteptare nu are nevoie de conturi; un câmp de e-mail este suficient.

Cele patru metode comune de login

Multe aplicații combină două metode: autentificarea cu Google plus linkuri magice pe e-mail este o pereche populară, care acoperă majoritatea oamenilor fără să stocheze parole.

E-mail și parolă

Dacă oferi parole, acestea sunt obligatorii:

• Fă hash-ul parolelor cu un algoritm lent de hashing pentru parole. Ghidul OWASP pentru stocarea parolelor recomandă Argon2id, iar scrypt, bcrypt sau PBKDF2 sunt alternative. Nu stoca niciodată parolele în text simplu sau cu un hash general rapid.
• Resetările de parolă folosesc un link aleatoriu, de unică folosință, care expiră și este trimis la e-mailul verificat.
• Nu dezvălui ce e-mailuri au conturi. „Dacă acest e-mail este înregistrat, am trimis un link de resetare” este mai bine decât „Nu s-a găsit niciun cont”.
• Limitează ratele încercărilor de login și resetare, ca să încetinești ghicirea parolelor.
• Permite parole lungi și managere de parole; renunță la regulile care impun combinații ciudate de caractere.

Linkuri magice și coduri de unică folosință

Un link magic este un link de autentificare trimis pe e-mail utilizatorului. Dacă dă clic pe el, este logat. Un cod de unică folosință este aceeași idee, dar se scrie în loc să fie apăsat.

• Linkurile și codurile expiră repede și funcționează o singură dată.
• Linkul ar trebui să îl logheze pe utilizator pe dispozitivul pe care a dat clic, iar tokenul nu trebuie să rămână în jurnale sau în instrumentele de analitice.
• Ai nevoie de livrare de e-mail fiabilă — vezi cum trimiți e-mailuri din aplicația ta. Testează cu Gmail și Outlook și verifică folderele de spam.

Sign in with Google (și alți furnizori OAuth)

„Sign in with Google” folosește OAuth și OpenID Connect: Google confirmă cine este utilizatorul și îi spune aplicației e-mailul și numele lui. Configurarea, la septembrie 2026, se face în secțiunea Google Auth Platform din Google Cloud Console:

1. Creează sau selectează un proiect și completează pagina Branding — ce văd utilizatorii pe ecranul de consimțământ (numele aplicației, e-mailul de suport, logoul).
2. Pe pagina Clients, creează un client de tip „Web application”.
3. Adaugă authorized JavaScript origins și redirect URIs — adresele exacte la care rulează aplicația ta și la care Google trimite utilizatorii după autentificare.
4. Stochează ID-ul clientului și secretul clientului în secretele aplicației.

Lucruri care se strică frecvent, conform documentației OAuth a Google:

• redirect_uri_mismatch: adresa de redirecționare trebuie să se potrivească exact, inclusiv http vs. https, majusculele și eventuala bară de la final. Adaugă una pentru adresa de previzualizare și una pentru domeniul tău live.
• HTTPS obligatoriu: URI-urile de redirecționare trebuie să folosească HTTPS, cu excepția localhost în timpul dezvoltării.
• Parametrul state ar trebui verificat la întoarcere, ca protecție împotriva cererilor cross-site falsificate. Bibliotecile bune o fac pentru tine.

Dacă ceri doar informații de bază de autentificare (nume, e-mail, profil), Google spune că verificarea aplicației nu este obligatorie. Cererea accesului la Gmail, Drive sau Calendar ale utilizatorilor este altceva și necesită verificare.

Îl construiești sau folosești un furnizor?

Primele două sunt rezonabile. Furnizorii găzduiți fac mai mult pentru tine, dar adaugă o dependență și uneori costă per utilizator activ; verifică prețurile actuale pe site-urile lor. Bibliotecile păstrează totul în baza ta de date, dar îți lasă mai multe de configurat corect. Indiferent ce alegi, cere AI-ului să o folosească în loc să scrie de mână logica de parole sau de sesiune.

Roluri și permisiuni

Login-ul îți spune cine este cineva. Permisiunile decid ce poate face. Păstrează lucrurile simple la început:

Reguli mai importante decât numele rolurilor:

• Verifică pe server, de fiecare dată. Ascunderea unui buton în pagină nu oprește pe nimeni să apeleze direct API-ul.
• Limitează după proprietar. Un membru care cere „rezervarea 123” ar trebui să o primească doar dacă este a lui.
• Utilizatorii nu se pot promova singuri. Ignoră câmpurile de rol trimise din browser la actualizările de profil.
• Implicit, fără acces. Rutele noi ar trebui să ceară login, dacă nu decizi altfel.

Testează cu două conturi: autentifică-te cu unul, notează ID-ul unei înregistrări, apoi autentifică-te cu celălalt și încearcă să o deschizi. Lista noastră de verificare de securitate are testul complet.

Securitatea sesiunii

După login, aplicația îl reține pe utilizator printr-o sesiune — de obicei un cookie. Ghidul OWASP pentru gestionarea sesiunilor recomandă:

• Cookie-uri de sesiune setate cu Secure (doar HTTPS), HttpOnly (ilizibile de scripturile paginii) și SameSite
• Un ID nou de sesiune emis la login și din nou când privilegiile se schimbă
• Expirare după inactivitate și o durată maximă absolută de viață, impuse pe server
• Deconectare care încheie sesiunea pe server, nu doar șterge cookie-ul
• Sesiunile invalidate când utilizatorul își schimbă parola

Stocarea token-urilor de login în local storage al browserului este frecventă în tutoriale, dar îi expune pe oricare script care rulează pe pagină; cookie-urile sigure sunt de obicei un implicit mai bun pentru aplicațiile web.

Un prompt care acoperă esențialul

Adaugă conturi de utilizator în această aplicație. Utilizatorii se pot înregistra și se pot autentifica cu e-mail și parolă, sau cu Google. Folosește [biblioteca sau furnizorul] în loc de cod de autentificare scris de mână. Fă hash-ul parolelor cu Argon2id sau bcrypt. Adaugă resetarea parolei pe e-mail, cu un link de unică folosință care expiră într-o oră. Păstrează sesiunile în cookie-uri sigure, HttpOnly. Protejează /dashboard și fiecare rută /api, ca doar utilizatorii logați să le poată folosi, și asigură-te că utilizatorii pot vedea doar propriile proiecte. Adaugă un rol „admin” care poate vedea toți utilizatorii; doar adminii pot ajunge la /admin, verificat pe server.

Apoi testează: înregistrează-te, deconectează-te, autentifică-te, resetează parola, încearcă un URL privat când ești deconectat și încearcă înregistrarea altui utilizator.

Greșeli frecvente în login-ul construit cu AI

• Protecție doar în pagină. Pagina redirecționează utilizatorii deconectați, dar API-ul returnează date oricui.
• Secrete în browser. Secretele clientului OAuth și cheile de administrare ale furnizorului de autentificare trebuie să stea pe server.
• Adresele de previzualizare și cele live amestecate. URI-ul de redirecționare al Google sau linkul de resetare din e-mail indică spre previzualizare, deci login-ul se strică după publicare.
• Fără verificarea e-mailului. Oricine se poate înregistra ca anyone@company.com. Verifică e-mailul înainte să acorzi ceva legat de acea adresă.
• Testarea doar a cazului fericit. Încearcă parole greșite, linkuri expirate și un al doilea cont.

Adăugarea login-ului în Mythex

În Mythex, login-ul pentru utilizatorii aplicației tale este ceva ce adaugi în aplicație — este separat de propriul tău cont Mythex. Mythex nu oferă un produs de autentificare integrat, deci aduci o bibliotecă de autentificare sau un furnizor și cheile lor:

1. Alege o abordare — de exemplu, e-mail și parolă stocate în propria bază de date, sau SDK-ul unui furnizor găzduit.
2. Dacă stochezi singur utilizatorii, aplicația are nevoie de o bază de date; cere-o în chat sau folosește /database.
3. Pune cheile furnizorului în secretele proiectului (/secrets sau setările proiectului).
4. Folosește un prompt ca cel de mai sus, apoi testează în Preview. Pentru autentificarea cu Google, adaugă URI-uri de redirecționare pentru adresa de previzualizare și pentru cea publicată.

Vezi Adaugă login în aplicația ta în documentație. Dacă construiești un produs cu plată, cum construiești un MVP SaaS acoperă împreună conturile și facturarea.

Întrebări