1. Introduction
Dans OAuth 2.0 [RFC6749], le contenu des jetons est opaque pour les clients. Cela signifie que le client n'a pas besoin de connaître quoi que ce soit sur le contenu ou la structure du jeton lui-même, s'il en existe. Cependant, il existe toujours une grande quantité de métadonnées qui peuvent être attachées à un jeton, telles que sa validité actuelle, les portées approuvées et des informations sur le contexte dans lequel le jeton a été émis. Ces informations sont souvent vitales pour que les ressources protégées prennent des décisions d'autorisation basées sur les jetons présentés. Étant donné qu'OAuth 2.0 ne définit pas de protocole permettant au serveur de ressources d'apprendre des méta-informations sur un jeton qu'il a reçu d'un serveur d'autorisation, plusieurs approches différentes ont été développées pour combler cette lacune. Celles-ci incluent l'utilisation de formats de jetons structurés tels que JWT [RFC7519] ou de mécanismes de communication inter-services propriétaires (tels que des bases de données partagées et des bus de services d'entreprise protégés) qui transmettent des informations sur les jetons.
Cette spécification définit un protocole qui permet aux ressources protégées autorisées d'interroger le serveur d'autorisation pour déterminer l'ensemble des métadonnées d'un jeton donné qui leur a été présenté par un client OAuth 2.0. Ces métadonnées incluent si le jeton est actuellement actif ou non (ou s'il a expiré ou a été révoqué d'une autre manière), les droits d'accès que le jeton porte (généralement transmis via les portées OAuth 2.0), et 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 de jeton permet à une ressource protégée d'interroger ces informations, qu'elles soient incluses ou non dans le jeton lui-même, permettant ainsi d'utiliser cette méthode conjointement avec ou indépendamment des valeurs de jetons structurés. De plus, une ressource protégée peut utiliser le mécanisme décrit dans cette spécification pour introspecter le jeton dans un contexte de décision d'autorisation particulier et déterminer les métadonnées pertinentes sur le jeton pour prendre cette décision d'autorisation de manière appropriée.
1.1. Conventions de notation
Les mots clés 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', et 'OPTIONAL' dans ce document doivent être interprétés comme décrit dans [RFC2119].
Sauf indication contraire, tous les noms et valeurs des paramètres de protocole sont sensibles à la casse.
1.2. Terminologie
Cette section définit la terminologie utilisée par cette spécification. Cette section est une partie normative de cette spécification, imposant des exigences aux implémentations.
Cette spécification utilise les termes "access token (jeton d'accès)", "authorization endpoint (point de terminaison d'autorisation)", "authorization grant (autorisation d'accès)", "authorization server (serveur d'autorisation)", "client", "client identifier (identifiant client)", "protected resource (ressource protégée)", "refresh token (jeton de rafraîchissement)", "resource owner (propriétaire de ressource)", "resource server (serveur de ressources)", et "token endpoint (point de terminaison de jeton)" définis par OAuth 2.0 [RFC6749], ainsi que les termes "claim names (noms de revendication)" et "claim values (valeurs de revendication)" définis par JSON Web Token (JWT) [RFC7519].
Cette spécification définit les termes suivants:
Token Introspection (Introspection de jeton) : L'acte de s'enquérir de l'état actuel d'un jeton OAuth 2.0 via l'utilisation du protocole réseau défini dans ce document.
Introspection Endpoint (Point de terminaison d'introspection) : Le point de terminaison OAuth 2.0 par lequel l'opération d'introspection de jeton est accomplie.