Introspection des jetons OAuth 2.0

L'introspection des jetons OAuth 2.0 définit une méthode qui permet à une ressource protégée autorisée d'interroger le serveur d'autorisation afin de déterminer les métadonnées associées à un jeton donné (soit un jeton d'accès, soit un jeton de rafraîchissement), fourni par un client OAuth. En fonction des métadonnées du jeton spécifique, cela permet au propriétaire de la ressource d'accéder à la ressource protégée.

Ces métadonnées comprennent :

• Si le jeton est actuellement actif (ou s'il a expiré ou été révoqué)
• Les permissions accordées par le jeton d'accès (généralement transmises via les étendues OAuth 2.0)
• Le contexte d'autorisation dans lequel le jeton a été accordé (y compris qui a autorisé le jeton et à quel client il a été émis)

L'introspection des jetons permet à la ressource protégée d'interroger ces informations, que ce soit ou non contenu dans le jeton lui-même.

Il existe deux types de jetons d'accès, selon la façon dont ils sont encodés :

• Basé sur un identifiant : Le jeton représente un identifiant aléatoire, difficile à deviner, associé à l'autorisation dans la base de données du serveur d'autorisation.
• Autonome : L'autorisation est encodée dans le jeton lui-même et est protégée par une cryptographie pour éviter la falsification. JSON Web Token (JWT) est la norme courante pour cette méthode.

Pour les jetons autonomes, les métadonnées liées à l'autorisation peuvent être directement analysées à partir du jeton d'accès. Cependant, pour les jetons basés sur un identifiant, la fonctionnalité d'introspection des jetons du serveur d'autorisation doit être utilisée pour valider/récupérer les métadonnées.

Demande d'introspection de jeton#

L'utilisation de jetons d'accès basés sur un identifiant nécessite une vérification avec le serveur d'autorisation via une requête réseau. Il existe un protocole standard pour cela appelé Introspection de Jeton OAuth 2.0 (RFC 7662).

La ressource protégée enverra le jeton au point d'extrémité d'introspection du serveur d'autorisation, et en retour, elle recevra un objet JSON contenant les paramètres du jeton.

Notez que les demandes d'introspection ne peuvent pas être initiées arbitrairement ; elles doivent répondre à l'une des conditions suivantes :

• Authentification à l'aide de crédentials (qui doivent être préenregistrées avec le serveur d'autorisation), ou
• Autorisation à l'aide d'un jeton d'accès.

En conséquence, dans cette interaction spécifique, la ressource protégée devient le client OAuth, et le serveur d'autorisation devient la ressource protégée.

Voici un exemple de demande d'introspection, où la ressource protégée s'authentifie en utilisant un ID client et un secret client, obtenus après s'être enregistré en tant que client OAuth auprès du serveur d'autorisation.

Voici un exemple de demande d'introspection qui utilise directement un jeton d'accès. Le jeton d'accès peut être obtenu directement depuis le point d'extrémité /token en utilisant les crédentials d'une application machine-à-machine enregistrée et le type de subvention client_credentials.

Réponse d'introspection de jeton#

Le paramètre le plus important est active, qui est une valeur booléenne. Si true, cela indique que le jeton est valide, et l'objet JSON inclura d'autres détails sur le jeton, tels que les valeurs des étendues. Si false, le jeton est soit invalide, soit expiré, et la ressource protégée doit renvoyer une réponse 401 Unauthorized avec le code d'erreur invalid_token.

Voici un exemple de réponse pour un jeton valide :

À l'exception de active, qui est requis, tous les autres paramètres sont optionnels.

La ressource protégée peut utiliser ces champs supplémentaires pour déterminer les permissions d'accès, de la même manière qu'elle analyserait et validerait un jeton d'accès JWT.