Custom header X-REQUESTED-WITH: XMLHttpRequest ecrit depuis le javascript et verifié par le backend a chaque requete (dans l’idee il y aurait besoin que des POST/PUT/DELETE mais bon ca fait pas de mal) <-- Empeche les attaque CSRF
Token d’identification JWT en cookie Secure;HttpOnly qui expire au bout de 7 jour, la seule facon de recuperer ce cookie c’est avec son mot de passe. <-- Empeche les attaque XSS de lire le token pour le reutiliser.
Le JWT est encodé avec une private key sur notre serveur <-- Permet de valider le token et tant que la private key est secure, impossible de generer des tokens.
Le JWT contiendra les informations stateless suffisante pour identifier un utilisateur, 16XXXX peut faire l’affaire par exemple <-- Stateless permet d’identifier un utilisateur sans necessairement lookup une BDD
Dans l’idée avoir une public key capable de valider le token si jamais on veut utiliser le portail comme facon d’authentification secure pour d’autres sites, ce n’est pas high-priority mais au moins le JWT permettra cette possibilité.
================
What is to be done:
[x] Endpoint with username and password to get a token
[x] Simple endpoint to check if the token is valid
[ ] Endpoint to reset password (Non authenticated)
FlorianVeaux
commented
6 years ago
X-REQUESTED-WITH: XMLHttpRequestecrit depuis le javascript et verifié par le backend a chaque requete (dans l’idee il y aurait besoin que des POST/PUT/DELETE mais bon ca fait pas de mal) <-- Empeche les attaque CSRFSecure;HttpOnlyqui expire au bout de 7 jour, la seule facon de recuperer ce cookie c’est avec son mot de passe. <-- Empeche les attaque XSS de lire le token pour le reutiliser.16XXXXpeut faire l’affaire par exemple <-- Stateless permet d’identifier un utilisateur sans necessairement lookup une BDD================ What is to be done: