concepts de base sur les jetons d'authentification

 jeton opaque :

illisible pour le serveur qui le reçoit. le serveur doit le revoyer au serveur d'authentification pour que ce dernier lui renvoie les infos (identités, droits,...) qu'on appelle les claims.

L’application (ou API) reçoit un jeton opaque et appelle un endpoint d’introspection, prévu par la norme OAuth2

il ne sert à rien sans appel au serveur d'auth.

plus securisé, permet la révocation immédiate et des implémentations complexes. il est moins performant.

à l'inverse :

le jeton auto-porté (self-contained)

souvent JWT.

explication simplifié : le jeton est signé par le serveur d'auth. avec sa clé privé. le serveur qui le recoit peut le décoder avec la clé public du serveur d'auth. Ca garantit qu'il provient de lui, mais peut être intercepté et divilguer des informations sensibles sur l'indentité de l'utilisateur.

Différence majeure : controle centralisé et revocation immédiate pour le jeton opaque. pas de cache de clé à implémenter ni de distribution de clé publique.

Authentification de service à service

- si une appli A demande une authentification auprès d'un serveur auth elle recoit un jeton opaque ou jwt.
- pour simplifer la communication elle peut transmettre le jeton à l'appli B de sorte que l'appli B identifie le user sans besoin de repasser par le serveur d'authentification. 
mais il faut sécuriser en demandant à A de signer le jeton de sorte que B ait confiance.