A lucrat cineva cu stack-ul asta din titlu si sa faca cookie-based auth?
Stiu ca pentru unii dintre voi e trivial task-ul, dar pentru mine e prima data cand implementez autentificare intr-o aplicatie si as avea niste intrebari (am cautat ceva tutoriale si documentatie dar nu mi-e foarte clar cum trebuie facut totul si la cat de important e feature-ul, n-as vrea sa risc).
Nu folosesc Identity / Entity Framework dar nu ar trebui sa aiba prea mare importanta.
Deci daca vrea cineva sa dea o mana de ajutor, anuntati-ma va rog
Am vazut si tutorialele astea.
S-a mers initial pe ideea de autentificare “clasica” (cookie-based)
Intrebarea mai corecta este : cum setez si pe partea de frontend ca s-a emis un cookie, cu o data de expirare & so on.
Nu vorbesc tehnic, ci mai degraba partea logica, cum functioneaza autentificarea cand e vorba de cookie-uri.
Gracias !
Am revenit
Implementez pana la urma autentificare cu JWT
A mai facut cineva asa ceva? Unde ati salvat token-ul ? (localStorage / sessionStorage / cookie)
Cum rezolvati situatiile cand expira token-ul? Refresh token cu data mai mare de expirare? A gasit cineva o metoda mai interesanta?
Mersi
As arunca mai intai o privire aici, unde se explica pros and cons la autentificarea folosind JWT. Daca totusi ramai la JWT tokens, este precizat in articol ca stocarea in cookie te face vulnerabil la csrf (un cheatsheet f util aici).
Misto articol. Ce bine era daca l-as fi citit acum cateva zile… :))
Argumente solide !
Oricum, stocarea in localStorage te face vulnerabil la XSS, stocarea in cookie te face vulnerabil la CSRF.
O sa mai testez si alte variante de autentificare / autorizare
Nu ma pricep neaparat la cum se fac lururile astea in .net (numele librariilor ma refer), dar poti folosi linistit CSRF tokens, ar trebui sa fie in .net land implementari similare celor pe care le-am folosit eu in lumea PHP si Python, unde vin cam la pachet cu frameworkul (ex Django are nativ csrf tokens).
Ideea de baza aici ar fi sa ai 2 tokenuri diferite: unul inainte de autentificare si altul dupa, deci sa nu cumva sa refolosesti acelasi token si doar sa schimbi un flag in server-side. Daca lucrezi cu un token nou creat dupa autentificare, care expira dupa x timp, ai scapat de csrf.
Cum decizi intr-un SPA ca un utilizator este “autentificat” daca faci cookie-based auth?
Parsezi cookie-ul si vezi informatiile din el ca sa vezi ce rol are, ce username samd?
…in cazul in care ai lucrat vreun pic cu SPA sau mai ai vreun articol misto de share-uit
Nu ești SPA până la capăt. autentificare o să presupună și un page reload, chiar daca faci tot flow-ul de auth pe partea ta. Dacă depinzi de Google, Facebook etc cu atât mai mult, că flow-ul standard presupune un număr de redirecturi.
IMO, .net trebuie să aibă un modul de auth pe care tu doar s-al configurezi. Dacă nu, auth0 s-ar putea să aibă unul plus o sumedenie de alte goodies.
E o experiență buna să-ți faci propriul sistem din asta, dar este și laborios, risc uriaș de securitate și mai bine lăsat pe o librărie battle tested.
De ce zici ca nu-s SPA pana la capat? Momentan nu depind de Google si Facebook. Slabe sanse sa se intample asta in viitorul apropiat.
Da, .net are niste module de autentificare cu JWT / Cookie pe care le si folosesc. Atata tot ca nu iau solutia lor completa pentru ca nu se aplica pe ce am eu nevoie, ci doar o parte. Iar auth0 cel mai probabil sare din discutie pentru ca exista o oarecare reticenta fata de librariile 3rd party…nu ma intreba de ce.
Imi dau seama de riscuri, I’m trying to do my best here. E prima data cand ma ocup de o chestie de genul asta intr-un proiect. Pana acum mi-a fost de-ajuns sa iau securitatea/autentificarea ready-made. Dar e ok, am mai invatat multe chestii cu ocazia asta.
Pana la urma cred ca o sa ii creez o sesiune pe server pe care o s-o verific la fiecare apel API. (indiferent ca e autentificare cu cookie (a se citi sesiune) / JWT tot ai nevoie de o sesiune pe server. Asa ca pot la fel de bine sa merg pe modelul battle-tested de autentificare pe baza de sesiune).
M-am mai gandit aseara si cred ca pana la urma ca o sa ii creez un cookie pe server, trimis inapoi in frontend atasat response-ului. Iar response-ul nu va fi un Status.OK ci probabil va fi chiar un obiect cu datele utilizatorului. (ori asta, ori trimit un Status.OK si apoi mai fac un apel sa iau datele utilizatorului pe care le voi salva in localStorage/cookie - e vorba doar de username si diverse date legate de preferintele lui - tema folosita, date-format, …)
In Django nu e foarte complicat și ce ai zis tu poate fi făcut cu o chestie numita midlleware. Requestul trece mai întâi prin midlleware apoi merge către aplicația Django in sine. Așa verificam daca requestul are atașat un anume cookie. Dacă nu, se făce redirect catre pagina de login de unde, la success, se întoarce un response cu un cookie de sesiune atașat. Acum daca nu mă înșel acel cookie poate primi și un parametru max-age , dar funcționalitatea asta nu este suportata de toate browserele.
Nu-mi dau seama daca modul in care imi explici “o chestie numita middleware” este ironic sau chiar imi zici ca la elevi de clasa a 10a :))
Da, chestia aia built-in din .NET de care ziceam mai sus se ocupa de validarea cookie-ului (plus prelungirea duratei de viata a cookie-ului atunci cand fac requesturi - cred ca sliding expiration se numeste)
Imi dau seama ca mai mult intrebarea mea e pe partea de frontend…cum configurez UI-ul in functie de state-ul utilizatorului (autentificat sau nu). Dupa ce-l autentific, mai fac un request sa iau datele lui personale? Cand il autentific trimit inapoi un obiect cu datele userului?
Ca mai apoi, la fiecare change-route din FE sa verific daca utilizatorul este autentificat, ce rol are, daca are acces pe pagina pe care vrea sa intre, etc
