
![[8.5.5.4 ou ultérieure]](../ng_v8554.gif)
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
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
Procédure
- 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.
- 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.
- Envoyez la demande GET ou POST à l'URL du noeud final Introspection.
Résultats
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.
Exemple
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"
}