| access management
OIDC et la chambre des secrets
Chapitre 01 : « Très bien, gardez vos secrets »
Avec la réglementation RGPD, les acteurs du numérique doivent apporter un soin particulier à la protection des données personnelles. Dans la réalité, c’est un défi de taille, surtout dans le cadre du Customer Identity and Access Management (CIAM) où les applications peuvent nécessiter l’accès à une donnée personnelle – sans pour autant les voir toutes. La notion de scope répond partiellement au besoin, confiant à l’utilisateur final la responsabilité de consentir au partage de certaines données.
Pour des applications sensibles cependant, il n’est pas rare de devoir inclure une donnée confidentielle mais nécessaire à l’appel d’une API dans le jeton d’accès. Dans d’autres cas, c’est la politique de sécurité qui requiert un token opaque.
Plusieurs solutions s’offrent alors pour assurer une opacité partielle ou totale de l’access token en faisant varier son format :
- Référence : l’access token a la forme d’un texte alphanumérique aléatoire et court.
- Dans ce cas, un client OAuth 2.0 autorisé à accéder aux données sensibles peut faire appel au endpoint d’introspection pour connaître les claims associés à l’access token.
- Auto-porté : L’access token contient l’ensemble de ses informations sous la forme d’un JWT qui peut être totalement ou partiellement opaque :
- JWE (Json Web Encryption) permet de chiffrer le JWT assurant sa confidentialité ;
- SD-JWT (Selective disclosure JWT), nouveauté du draft éponyme qui permet de dissimuler la valeur de certains claims et de ne les divulguer qu’à certains « vérificateurs ». Il n’existe toutefois pas encore d’implémentation de ce draft dans les produits de fédération.
Chapitre 02 : JWE
JWE (Json Web Encryption) est un mécanisme permettant de chiffrer un jeton JWT et de rendre l’ensemble de son contenu confidentiel. Cela peut être utile quand un token sous la forme d’une référence ne suffit pas ou que HTTPS ne fournit pas une sécurité satisfaisante sur le réseau de l’entreprise.
Besoin de conseils pour sécuriser votre entreprise ?
Faisant partie intégrante du framework JOSE (Json Object Signature and Encryption), il n’est cependant pas souvent utilisé.
A – Format d’un token JWE
La RFC 7516 de Json Web Encryption définit plusieurs formats pour JWE, le plus utile étant la sérialisation compacte illustré ci-dessous :
La première chose que l’on constate concernant le token JWE est son entête, laquelle contient les éléments permettant d’identifier la clé de déchiffrement à utiliser.
JWE permet de chiffrer un JWT selon deux modes :
- Chiffrement symétrique (AES-GCM / AES Key wrap / Direct)
- Une clé secrète est partagée entre le serveur d’autorisation et le serveur de ressource ;
- La clé du contenu aléatoire est protégée par la clé secrète, sauf si le mode « Direct » est utilisé – auquel cas la clé symétrique est directement utilisée pour chiffrer le contenu.
- Chiffrement asymétrique (RSAES-OAEP / ECDH-ES)
- Le serveur d’autorisation chiffre le token avec une clé de contenu symétrique (CEK) aléatoire – qu’il chiffre avec une clé publique ;
- Le serveur de ressource déchiffre la clé de contenu avec sa clé privée, puis déchiffre le token.
Expliquons les claims présents dans l’entête :
- alg : Algorithme de chiffrement de la clé de session symétrique ;
- enc : Algorithme de chiffrement du contenu ;
- cty : Type de contenu ;
- pi.atm : Spécifique à PingFederate, ce claim identifie le « access token manager » qui a fabriqué l’access token ;
- kid : Identifiant de la clé de chiffrement ;
- x5t : Empreinte du certificat associé à la clé de chiffrement (optionnel) ;
- x5c : Chaîne de certification associée à la clé de chiffrement (optionnel).
B – Types de chiffrements supportés
C – Exemple de cas d’usage
Assez souvent, les cas d’usage B2C et B2B font chacun intervenir deux serveurs de fédération différents – malgré le fait que les APIs soient protégées par une même passerelle.
Dans un tel cas de figure, il n’est pas envisageable d’utiliser des access_token sous la forme de référence car la passerelle ne saurait plus explicitement auprès de quel serveur de fédération vérifier le contenu et la validité du token.
Dans de tels cas de figure, l’utilisation de JWE est souhaitable en raison de son format car il permet à l’API Gateway de déchiffrer son contenu et de récupérer l’émetteur (issuer) du token.
Avec OIDC, la meilleure pratique consiste à retourner dans un premier temps un access token dont le seul rôle sera de permettre l’utilisation du UserInfo endpoint. Ce token peut être une simple référence. Pour accéder à une API, il convient de procéder en premier lieu à un échange de token pour obtenir un token JWE.
L’API Gateway procède de la façon suivante pour déchiffrer le token JWE :
Il est à noter que l’introspection endpoint ne peut consommer qu’un token JWE chiffré avec une clé symétrique ou bien un token JWT en clair.
Chapitre 03 : Révélations sélectives (SD-JWT)
Défini par le draft IETF « Selective Disclosure for JWTs (SD-JWT) » (https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/), les SD-JWT offrent un mécanisme permettant de ne divulguer la valeur de certains claims qu’à des vérificateurs approuvés.
A – Concepts de SD-JWT
Le draft SD-JWT définit trois nouvelles structures de données :
Le draft SD-JWT désigne également trois entités sans pour autant les rapporter des acteurs spécifiques des protocoles OAuth 2.0 et OIDC :
- L’émetteur (issuer) : une entité chargée d’émettre les SD-JWT et les SVC ;
- Le détenteur (holder) : une entité chargée de contrôler les SD-JWT de divulguer le contenu des claims ;
- Le vérificateur (vérifier) : une entité qui demande, contrôle et extrait les claims du SD-JWT-R.
B – Principe de fonctionnement
Le draft contient le schéma suivant pour expliquer le principe de fonctionnement de SD-JWT (noter que la demande de divulgation partant des vérificateurs a été ajoutée) :
Lorsque que l’émetteur crée un SD-JWT, chaque claim est masqué et remplacé par une empreinte (hash salé). En parallèle, l’émetteur crée un second document, le SVC, qui contiendra les valeurs en clair des claims ainsi que leurs empreintes. Il est à noter que seul le SD-JWT est signé par l’émetteur : les empreintes des claims permettent en effet de propager l’intégrité du SD-JWT au SVC.
Ces deux documents sont confiés de façon combinée au détenteur qui deviendra en quelque sorte le gardien des secrets, responsable de la divulgation des claims. Toutefois, le draft ne définit pas comment les vérificateurs peuvent demander la divulgation des claims. En revanche, le draft précise le format des SD-JWT-R permettant de présenter les claims divulgués aux vérificateurs.
C – Application possible
Le scénario suivant est une idée d’application de SD-JWT.
Imaginons, une application SPA doit appeler plusieurs APIs différentes avec un access token. Chacune de ces APIs ont besoin d’extraire de l’accès token des données personnelles différentes ou des données métier confidentielles.
Dans l’exemple présenté ci-dessous, le client OAuth 2.0 est une application SPA qui récupère auprès du serveur d’autorisation un jeton d’accès SD-JWT – après que ce dernier ait authentifié l’utilisateur. Le « détenteur » pourrait éventuellement, ici, être un backend, mais on peut également imaginer que ce rôle soit également confié au serveur d’autorisation.
L’API 1 reçoit un SD-JWT, dont elle peut vérifier la signature, mais dont elle ne peut pas lire tous les claims. Elle doit donc faire une demande de divulgation au détenteur. Dans sa demande, elle précise le sous-ensemble de claims à divulguer, le SD-JWT est éventuellement fourni des informations de connexion (client id/client secret).
L’API 2 est en mesure de faire de même, mais peut n’être autorisée qu’à demander la divulgation d’un deuxième sous-ensemble de claims.
Épilogue : « Chouette ! Où est-ce qu’on va ? »
Nous venons de voir trois méthodes permettant de limiter la divulgation de données personnelles, au travers de l’utilisation des protocoles OAuth 2.0 et OIDC – rendant les token opaques.
La technique reposant sur un access token au format « référence » n’est pas applicable aux ID Token d’OIDC. Tandis que la technique reposant sur JWE nécessite en effort pour intégrer le déchiffrement des tokens pour les acteurs cherchant à le consommer mais peut s’appliquer aux ID tokens.
Enfin, la technique SD-JWT est très prometteuse, elle peut s’appliquer à tout token JWT et ne nécessite pas d’efforts particuliers pour intégrer un déchiffrement comme pour JWE. Cependant, il n’est pour le moment pas encore implémenté.
