Appel du noeud final Introspection pour OpenID Connect

Le noeud final Introspection permet aux détenteurs de jetons d'accès de demander un ensemble de métadonnées concernant un jeton d'accès du fournisseur OpenID Connect qui l'a émis. Le jeton d'accès doit avoir été obtenu via l'authentification OpenID Connect ou OAuth.

Avant de commencer

Lorsqu'un service de ressource ou une application client appelle le noeud final Introspection, ils doivent s'enregistrer eux-mêmes en tant que client OAuth 2.0 normal sur le serveur OpenID Connect. Mes métadonnées client enregistrées doivent inclure l'attribute introspectTokens = true.

Pourquoi et quand exécuter cette tâche

Les informations qui figurent au sein des jetons d'accès utilisés dansOpenID Connect et OAuth 2.0 sont opaques pour les clients. Cela permet aux ressources ou aux clients protégés de prendre des décisions d'autorisation basées sur les métadonnées renvoyées par le fournisseur OpenID Connect au sujet du jeton d'accès.

Un serveur Liberty avec OpenID Connect activé peut accéder au noeud final introspection OpenID Connect à l'URL suivante :

 https://server.example.com:443/oidc/endpoint/<provider_name>/introspect
Eviter les incidents : Si vous utilisez un proxy sortant, notez que le fournisseur de ressource OpenID Connect ne fournit aucun moyen d'acheminer automatiquement des demandes via un hôte proxy.

Si vous devez utiliser un proxy pour accéder au fournisseur OpenID Connect, la valeur que vous entrez pour n'importe quelle propriété d'URL liée à un fournisseur OpenID Connect doit contenir l'hôte et le port de proxy et non l'hôte et le port de fournisseur OpenID Connect externe.

Dans la plupart des cas, vous pouvez remplacer l'hôte et le port de fournisseur OpenID Connect par l'hôte et le port de proxy. L'URL que vous entrez doit être visible à la fois pour le fournisseur et le client (navigateur ou application). Pour obtenir d'autres conseils sur la méthode permettant de déterminer l'URL à utiliser, contactez votre administrateur de proxy.

Dans cet exemple, le client suppose que le port SSL est défini sur 443.

Procédure

  1. Définissez l'authentification client avec l'ID et le mot de passe client d'un client OpenID Connect enregistré dans l'en-tête HTTP Basic Authorization d'une demande GET or POST. L'ID et le mot de passe du client sont codés à l'aide de l'algorithme de codage application/x-www-form-urlencoded. L'ID du client codé est utilisé comme nom d'utilisateur et le mot de passe codé est utilisé comme mot de passe.
  2. Incluez la valeur de chaîne pour le jeton d'accès en tant que paramètre dans la demande GET ou POST sur le noeud final Introspection.
  3. Envoyez la demande GET ou POST à l'URL du noeud final Introspection.

Résultats

Une fois ces étapes effectuées, vous disposez d'une demande HTTP valide qui peut être envoyée au noeud final Introspection comme illustré dans la section Exemples.

Pour les demandes valides, le noeud final Introspection renvoie une réponse HTTP 200 avec objet JSON au format application/json qui inclut les informations suivantes, selon que le jeton d'accès est actif ou expiré.

Lorsque le jeton d'accès est actif, le noeud final renvoie active:true, ainsi que les informations supplémentaires suivantes dans l'objet JSON :

  • active : indicateur booléen indiquant si le jeton d'accès est actif.
  • client_id : identificateur du client OpenID Connect Client ayant sollicité le jeton d'accès.
  • sub : propriétaire de la ressource ayant autorisé le jeton d'accès.
  • scope : liste des portées associées au jeton d'accès, séparées par des espaces.
  • iat : horodatage sous forme d'entier, mesuré en secondes depuis le 1er janvier 1970 (Temps Universel Coordonné), indiquant quand le jeton d'accès a été émis.
  • exp : horodatage sous forme d'entier, mesuré en secondes depuis le 1er janvier 1970 (Temps Universel Coordonné), indiquant quand le jeton d'accès va arriver à expiration.
  • realmName : nom de domaine du propriétaire de la ressource.
  • uniqueSecurityName : nom de sécurité unique du propriétaire de la ressource.
  • tokenType: type de jeton d'accès. Pour OpenID Connect, cette valeur est Bearer.
  • grant_type : chaîne indiquant le type d'accord ayant généré le jeton d'accès. Les valeurs possibles sont : authorization_code, password, refresh_token, client_credentials, resource_owner, implicit et urn:ietf:params:oauth:grant-type:jwt-bearer.

Si le jeton d'accès a expiré, et que l'authentification fournie est valide, ou si le jeton d'accès fourni est de type erroné, le noeud final renvoie active:false dans l'objet JSON.

Remarque : Pour pouvoir effectuer une introspection de jeton d'accès, un client ou un service de ressource doit s'enregistrer lui-même en tant que client auprès du fournisseur OpenID Connect, et les métadonnées du client doivent avoir metadata must have introspect_tokens défini sur true.

Exemple

Les exemples ci-après illustrent un jeton d'accès actif et expiré ainsi qu'une demande.

Voici un exemple de demande :

  POST /register HTTP/1.1
 Accept: application/x-www-form-urlencoded
 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
     token=SOYleDziTitHeKcodp6vqEmRwKPjz3lFZTcsQtVC

Voici un exemple de réponse pour un jeton d'accès actif :

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
{  
   "exp"                : 1415307710,
   "realmName"          : "BasicRealm",
   "sub"                : "testuser",
   "scope"              : "openid scope2 scope1",
   "grant_type"         : "authorization_code",
   "uniqueSecurityName" : "testuser",
   "active"             : true,
   "token_type"         : "Bearer",
   "client_id"          : "pclient01",
   "iat"                : 1415307700
}

Voici un exemple de réponse pour un jeton d'accès expiré :

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 {
     "active":"false"
 }

Icône indiquant le type de rubrique Rubrique Tâche

Nom du fichier : twlp_oidc_introspection_endpoint.html