Functionalitatea este in felul urmator:
Pe baza email si parola, te autentifici in backend si primesti raspuns un token pentru user. Tokenul respectiv se salveaza in front-end in Local storage.
Cand vrei sa apelezi rute din backend pentru acel user, de ex contul meu, anunturile tale etc pentru acele rute adaugi la request in header, Authorization Token d6ea98c5afefdf2fb4963806c95568a76ed4aca9, unde tokenul e cel salvat in local storage dupa ce te-ai logat.
Backendul verifica acel Token in tabela Tokens pentru acel user si daca e corect intoarce response.
Cand te deloghezi din front end, apelezi functia logout, aceasta sterge AuthToken din Local storage si la randul ei apeleaza functia logout din backend care sterge tokenul pentru user din tabela de Tokens.
Daca user-ul din front va face apeluri catre backend unde e nevoie de token va trebui sa se logheze din nou si astfel se obina un nou Auth token cu care sa faca request.
Pana cum tokenul se sterge la logout in front-end din Local Storage si in Back-end din tabela de Tokens.
Tu ai spus.
- Nu contează dacă tokenul expiră după o lună sau după zece;
- Dacă userul schimbă parola, se invalidează toate tokens existente
Cazul in care userul e logat in cont, exista Auth token in local storage si userul navigheaza catre url sa isi schimbe parola si face un apel catre backend ruta change-password.
In Backend am 2 variante:
a) doar ii schimb parola, caz in care functionarea nu se schimba cu nimic, tokenul e in continuare salvat in Local storage pentru Front end si exista si in tabela de tokens din Backend
b) Poate ca ar fi o masura de siguranta, daca de ex user-ul a fost logat pe mai multe device-uri si Auth token e salvat in local storage, cand schimb parola din backend sa sterg si tokenul din tabela de Tokens.
Nu stiu daca tu te-ai referit la acest aspect la punctul 2.
ceva gen
# Set the new password
user.set_password(serializer.validated_data['new_password'])
user.save()
# Invalidate existing auth tokens if any
Token.objects.filter(user=user).delete()
In acest caz in backend tokenul nu mai exista, dar a ramas cel din Front-end din local storage dar care nu mai e bun.
Userul din front ca sa faca requests are nevoie de un nou token pe care il obtine doar daca se autentifica.
Ca sa rezolv problema aceasta vad 2 variante:
a). cand schimba parola in front-end sa ii sterg si tokenul din Local storage si s ail redirectionez inapoi la pagina de login, ca sa se autentifice si astfel sa obtina un nou token.
Dar nu mi se pare user friendly.
b). Sa fac asta cumva in paralel, la schimbarea parolei, sa ii sterg tokenul vechi din Local storage si sa ii obtin un nou token de autentificare din backend, dar fara sa il oblig sa se autentifice.
Sa fac asta in spate cumva, trebuie sa vad cum as putea.
Sper sa se fi inteles functionalitatea 
Am 2 Intrebari:
- In functionalitatea prezentata sunt riscuri majore de securitate daca merg pe varianta asta cu token care nu expira?
Nu salvez CC sau alte date sensibile, dar totusi as vrea sa fie safe autentificarea.
Pot adauga JWT chiar daca am facut autentificarea in varianta de mai sus, dar ma intereseaza mai mult sa inteleg procesul si riscurile.
Am inceput astfel, datorita faptului ca Django rest e foarte cunoscut si daca ar fi fost un risc major de securitate presuspun ca nu ar fi lasat tokenul asa default.
Ca alternativa, pot folosi JWT caz in care nici nu mai fac apeluri catre db sau un pachet mai complex de autentificare GitHub - jazzband/django-rest-knox: Authentication Module for django rest auth care are si expiration time pentru token.
- Cat de important e atunci cand userul schimba parola sa ii invalidez/sterg tokenul existent?
Sunt si alte motive in afara de cel expus de mine?
Mersi
