Relier les points : Une exploration approfondie de la ressource OIDC et de vos jetons d'accès JWT
Cet article de blog vise à éclairer la relation entre les indicateurs de ressources OIDC et leur rôle dans l'obtention de jetons d'accès.
CharlesDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Dans une session précédente, nous avons présenté le protocole OpenID Connect (OIDC), les jetons d'actualisation, les jetons d'accès et les jetons ID, des composants essentiels pour construire une authentification robuste dans votre application. Cependant, des questions subsistent dans notre communauté, avec une demande récurrente : "Pourquoi mon jeton d'accès n'est-il pas un JWT ?"
Pour ceux qui sont nouveaux dans ces concepts, ou même pour ceux qui ont besoin d'une remise à niveau, cet article de blog vise à éclairer la relation entre les indicateurs de ressources OIDC et leur rôle dans l'obtention de jetons d'accès.
Si vous êtes familier avec le protocole OAuth 2.0, le terme “ressource” devrait vous parler. Comme OIDC est basé sur OAuth 2.0, il hérite de ce même concept.
Une "ressource" ou "ressource protégée" est une représentation d'une entité que l'application client souhaite accéder au nom de l'utilisateur authentifié. Il peut s'agir d'informations sur l'utilisateur, d'API de serveur, ou de toute autre donnée autorisée par votre serveur.
Selon le protocole, la ressource est un paramètre dans les demandes au serveur d'autorisation. C'est une valeur représentée par une URI absolue, comme https://mon-entreprise.com/api. Elle agit comme un identifiant pour la ressource, correspondant potentiellement à un emplacement accessible par réseau ou même à une URI unique mais fictive.
Dans Logto, vous pouvez créer une “ressource API” via la page “Console Admin → Ressources API”. Vous pouvez vous référer à cette documentation pour plus de détails.
Le jeton d'accès au format JWT (Jetons web JSON) n'est délivré que lorsque le paramètre "ressource" est spécifié lors de la demande de jeton d'accès, et il contient un ensemble de revendications, que vous pouvez déchiffrer et valider, par exemple, pour garantir l'intégrité du jeton et les autorisations de l'utilisateur.
Cette "ressource" devient alors l'une des revendications du jeton aud du JWT, indiquant l'audience prévue pour le jeton. Voir RFC-7519.
Ainsi, la relation devient claire :
Spécifiez l'indicateur de ressource lors de la demande d'un jeton JWT.
L'indicateur de ressource s'aligne avec la revendication du jeton aud.
Lors de la réalisation de demandes d'API, le jeton d'accès JWT doit être inclus en tant qu'en-tête du jeton porteur. Votre serveur API doit déchiffrer et valider la revendication aud et les autres revendications liées aux autorisations pour sécuriser la demande d'API.
Chaque jeton d'accès correspond à une seule ressource. Si vous avez plusieurs ressources API enregistrées avec différentes URI, demandez des jetons d'accès distincts pour chacune.
🤔 Mais que se passe-t-il si le client ne spécifie pas la ressource lors de la demande du jeton d'accès ?
Dans le cas de Logto, si l'indicateur de ressource n'est pas spécifié lors de la demande du jeton d'accès, le serveur d'autorisation suppose qu'il est pour le point de terminaison OIDC /userinfo, et ainsi un jeton d'accès opaque sera émis qui peut être utilisé plus tard par le client pour demander le profil utilisateur comme l'ID utilisateur, le nom, l'e-mail, etc., à partir du point de terminaison userinfo OIDC.
Dans n'importe quel SDK Logto, vous pouvez obtenir un tel jeton si vous appelez getAccessToken() ou directement le point de terminaison du jeton OIDC sans spécifier le paramètre resource.
Notez que ce jeton d'accès opaque n'est pas adapté pour vos propres demandes de ressources API, car il n'y a pas moyen de le vérifier sans demander au serveur OIDC.
Les ressources OIDC définissent des données ou des services spécifiques qu'une application client souhaite accéder au nom de l'utilisateur, avec des jetons d'accès JWT servant de moyen sécurisé pour cet accès. La revendication "aud" dans les jetons d'accès JWT s'aligne avec l'indicateur de ressource, aidant les serveurs à vérifier les autorisations lors des demandes de clients.
Dans Logto, le jeton d'accès opaque sert uniquement à extraire les informations de profil utilisateur du point de terminaison userinfo OIDC, tandis que les clients peuvent demander plusieurs jetons d'accès, chacun dédié à une ressource spécifique.
Nous espérons que cet article de blog dissipe tous les doutes et relie les points pour vous. N'hésitez pas à nous faire part de vos impressions.
