Référentiel Liberty[8.5.5.4 ou ultérieure]

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 de profil 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
Remarque : Dans cet exemple le port SSL du fournisseur OpenID Connect doit être 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 signifiant si le jeton d'accès est actif.
client_id
Identificateur client du client OpenID Connect qui a demandé le jeton d'accès.
sub
Propriétaire de la ressource qui a autorisé le jeton d'accès.
scope
Liste séparée par des espaces des portées qui sont associées au jeton d'accès.
iat
Horodatage entier, mesuré en secondes depuis le ler janvier 1970 UTC, indiquant la date à laquelle le jeton d'accès a été émis.
exp
Horodatage entier, mesuré en secondes depuis le ler janvier 1970 UTC, indiquant la date à laquelle le jeton d'accès va expirer.
realmName
Nom de domaine du propriétaire de la ressource.
uniqueSecurityName
Nom de sécurité unique du propriétaire de la ressource.
tokenType
Type du jeton d'accès. Pour OpenID Connect, cette valeur est Bearer.
grant_type
Chaîne indiquant le type d'octroi qui a 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

Dispositions pour les centres de documentation | Commentaires


Icône d'horodatage Dernière mise à jour: Wednesday, 2 September 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=twlp_oidc_introspection_endpoint
Nom du fichier : twlp_oidc_introspection_endpoint.html