Sécuriser une API REST (Partie 1) : Théorie - Code Heroes

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

  1. Le client POST des données de connexion au format JSON à l'URL servant au login (par exemple api/login)
  2. le serveur renvoie un token d'identification contenant des informations précises dans un format spécial: le Json Web Token (voir après)
  3. 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.
  1. Propriétés publiques : Il s’agit de noms normalisés tels que “email”, “name”, “locale”...
  2. 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')

✍ Écrire un commentaire

les commentaires relevant du SPAM seront filtrés et dégagés direct...

Quelle est le dernier caractère du mot lc31vhta ?