Sécuriser une API REST (Partie 1) : Théorie - Code Heroes
jeudi 12 septembre 2019 à 14:22
Un article très intéressant et très bien expliqué sur la sécurisation d'une API REST.
Bon, j'ai plus qu'à me mettre à faire une classe exprès pour éviter de me retaper tout le boulot à chaque fois...
...
Bon, là, j'ai la flemme, mais... bon.
Quelques notes pour plus tard
1. Déroulement des requêtes
- Le client POST des données de connexion au format JSON à l'URL servant au login (par exemple api/login)
- le serveur renvoie un token d'identification contenant des informations précises dans un format spécial: le Json Web Token (voir après)
- le token est envoyé avec chaque requête ultérieure pour être identifié côté serveur: si ok, envoi des données.
2. Le JSON Web Token (JWT)
Il est constitué de trois parties: header, payload et signature.
header:
Un Json qui contient le type et l'algo d'encodage du token : { "typ":"JWT, "alg":"HS256" } par exemple. Ce Json est ensuite encodé en Base64 pour former la première partie du token.
Le payload:
Un autre Json contenant les infos de l'utilisateur et lui aussi encodé en base64 pour former la seconde partie du token. ( voir ici pour les noms de clé )
1.Propriétés réservées :
- “iss” (Issuer) : l'identifiant du serveur de l'API;
- “sub” (Subject) : Identifiant de l'utilisateur;
- “aud” (Audience) : appli/site client;
- “iat” (Issued At) : Il s’agit de la date de génération du token;
- “exp” (Expiration Time) : Il s’agit de la date d’expiration du token.
- Propriétés publiques : Il s’agit de noms normalisés tels que “email”, “name”, “locale”...
- Propriétés privées : données propres à l'application.
La signature:
C'est un hash des deux premières parties utilisant l'algo précisé dans le header et une clé secrète détenue par le serveur (un salt, quoi).
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), 'secret')► Commentaires