Autentificare & autorizare

Autentificarea răspunde la întrebarea „cine ești?”, iar autorizarea la „ce ai voie să faci?”. Recash le tratează separat pe amândouă fără să stocheze vreodată o parolă.

Autentificare fără parole

Recash nu gestionează parole. Întreaga autentificare trece prin OAuth, ceea ce elimină din start o categorie întreagă de riscuri: nu există parole de stocat, deci nu există o bază de date de parole de spart; nu există formular de login, deci nu există atacuri prin forță brută sau completare de credențiale furate; nu există flux de resetare a parolei, cel mai des punct slab dintr-un sistem clasic de conturi.

Furnizori OAuth

Un utilizator se autentifică prin contul lui Google sau Facebook. Recash primește de la furnizor doar identitatea confirmată — nume, email, poză — și creează sau regăsește contul local pe baza adresei de email. Cheile secrete ale aplicației stau exclusiv pe server, niciodată în browser.

Google One Tap

Peste fluxul clasic, Google One Tap oferă autentificare cu o singură atingere, direct în pagină, fără redirect către un ecran separat. Comoditatea nu vine însă cu încredere oarbă: token-ul primit de la Google este verificat criptografic pe server, cu biblioteca oficială Google, înainte de a fi acceptat. Se confirmă că token-ul a fost emis chiar pentru această aplicație și că adresa de email este validată de Google; abia apoi contul este creat sau actualizat. Un token contrafăcut sau destinat altei aplicații este respins.

Sesiuni JWT

De ce JWT?

După autentificare, sesiunea este păstrată într-un token JWT semnat, ținut într-un cookie, nu într-o înregistrare din baza de date. Consecința directă: nicio cerere obișnuită nu trebuie să interogheze baza de date doar ca să confirme că utilizatorul este autentificat — semnătura token-ului este suficientă. Este mai rapid și scalează mai bine, pentru că verificarea nu depinde de baza de date.

Identitatea și rolul, purtate în token

La crearea sesiunii, identificatorul utilizatorului și rolul lui sunt scrise în token și expuse apoi aplicației prin obiectul de sesiune. Astfel, deciziile de autorizare care depind de rol au informația la îndemână, fără o interogare suplimentară, iar token-ul fiind semnat nu poate fi modificat de client fără ca semnătura să nu fie afectata.

Consecința pentru WebSocket

Pentru că sesiunea nu există ca înregistrare în baza de date, serverul WebSocket nu o poate valida acolo. De aceea folosește un mecanism propriu: aplicația cere un token temporar, aleator, valabil 60 de secunde, salvat în Redis și legat de utilizator; serverul WebSocket acceptă conexiunea doar pe baza lui. Detalii complete în Comunicare în timp real.

Protecția rutelor

Accesul este verificat în două etape, complementare, nu alternative.

Filtrul de la marginea aplicației

Înainte ca o cerere să atingă o pagină sau o rută API, un middleware verifică rapid prezența cookie-ului de sesiune și blochează din start ce nu are ce căuta acolo: paginile personale redirecționează un vizitator neautentificat către pagina principală, iar rutele API protejate îi răspund direct cu 401. Este un filtru ieftin, care oprește traficul neautentificat cât mai devreme.

Verificarea din fiecare rută

Filtrul de la margine se uită doar dacă există un cookie, nu îi verifică semnătura. Verificarea reală — decodarea și validarea criptografică a token-ului — se face în fiecare rută API sensibilă, chiar înainte de logica ei. Astfel, chiar dacă o cerere trece de primul filtru, nu poate face nimic fără o sesiune cu adevărat validă.

Niveluri de acces

Protecția nu este uniformă, ci potrivită fiecărei zone:

• paginile personale — profil, postare, notificări, setări — cer autentificare completă
• citirea postărilor este publică: oricine poate vedea harta de anunțuri, chiar și fără cont
• orice scriere — postare nouă, revendicare, anulare, finalizare — cere un cont autentificat; pe rutele de postări, doar metodele care modifică date sunt protejate, cititul rămâne liber

Autorizare pe obiect

Autentificarea confirmă identitatea, dar nu și dreptul asupra unui anumit obiect. De aceea, dincolo de „ești autentificat?”, fiecare acțiune verifică și „ai tu voie să faci asta, aici?”: doar autorul își poate anula propria postare deschisă, doar participanții la o colectare îi văd codul de confirmare, iar o cerere pentru un obiect care nu-ți aparține primește 403, nu datele.

De ce citirea este publică

Un vizitator neautentificat trebuie să vadă ce oferă platforma, ca motivație să-și facă cont — dar orice acțiune care implică bani sau reputație cere o identitate confirmată. Linia dintre „a privi” și „a acționa” este exact linia dintre public și autentificat.