Les tokens sont des interfaces
En architecture IAM, les tokens sont souvent traités comme des détails d'implémentation. En réalité, ce sont des interfaces entre Identity Provider, applications, API, gateways, systèmes de monitoring et parfois processus métier.
Un mauvais design de token crée couplage, exposition de données, confusion d'autorisation et fragilité opérationnelle. Un bon design est sobre, compréhensible, validé de manière cohérente et documenté pour les développeurs.
Minimiser avant d'enrichir
L'enrichissement de token peut être utile, mais il ne doit pas devenir un conteneur de données d'identité. Chaque claim doit avoir une raison d'exister.
Questions utiles :
- qui consomme le claim ;
- le claim est-il assez stable pour l'autorisation ;
- la valeur doit-elle être dans le token ou récupérée via API ;
- le claim expose-t-il une donnée sensible ;
- comment le claim est-il journalisé, surveillé et conservé.
Access tokens et ID tokens
Les ID tokens sont destinés au client. Les access tokens sont destinés aux ressources protégées. Confondre les deux fragilise les intégrations et les frontières d'autorisation.
La documentation développeur doit expliciter :
- audience prévue ;
- exigences de validation ;
- durée de vie ;
- claims requis ;
- claims optionnels ;
- comportement de refresh ;
- contraintes logout et session.
API Gateway et responsabilités de validation
Lorsqu'une API gateway intervient, les responsabilités de validation doivent être claires. Une gateway peut valider signature, issuer, audience, expiration, contraintes mTLS et certaines règles de politique. Les services backend doivent souvent encore appliquer l'autorisation métier.
L'erreur fréquente est de supposer que validation égale autorisation. Ce n'est pas le cas. La validation prouve que le token est structurellement et cryptographiquement acceptable. L'autorisation décide si l'appelant peut réaliser l'action.
Logging et monitoring
Les tokens ne doivent pas être loggés en clair. Les exigences de monitoring doivent définir les champs capturables, la corrélation et les événements utiles pour le SIEM.
Événements utiles : échec de validation, audience incorrecte, issuer incorrect, token expiré, réutilisation suspecte et échecs d'autorisation anormaux.
Points clés
- Les tokens sont des contrats, pas des conteneurs aléatoires.
- La minimisation des claims réduit exposition et couplage.
- Validation gateway et autorisation applicative doivent être documentées séparément.