Accueil > OpenID Connect OAuth Serveur dédié > Développer > OpenID Connect > Demande d’informations sur l’utilisateur (UserInfo Endpoint)

Demande d’informations sur l’utilisateur (UserInfo Endpoint)

Le point d’extrémité UserInfo du protocole OpenID Connect permet d’obtenir des informations sur l’utilisateur final authentifié.

Point d’extrémité UserInfo

L’URI est la suivante :

https://oa.dnc.global/userinfo

Contrôle de l’accès

Les demandes adressées au point de terminaison UserInfo doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token).
En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification.
S’agissant d’une spécification d’OpenID Connect, l’application appelante doit avoir été enregistrée avec le scope réservé ’openid’.

Client Credentials Grant
C’est l’approche la plus simple.
L’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification.
L’authentification est effectuée en utilisant l’authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l’inscription de l’application cliente sur le serveur.

Bearer Token
Cette approche nécessite un jeton d’accès pour autoriser la demande d’introspection.
Pour une application ce ne sera pas un problème dans la mesure où la demande UserInfo suivra généralement une demande de jetons.
Pour un serveur de ressource, cela est plus compliqué du fait de la durée limitée de validité du jeton d’accès, contraignant à une nouvelle demande de jeton. Une façon d’obtenir un tel jeton consiste à inscrire le serveur de ressource pour le flux Client Credential Grant.
L’authentification est effectuée en passant le jeton dans l’en-tête Authorization de la demande d’introspection.

Forme de la demande UserInfo

La méthode de transmission recommandée pour la transmission du jeton d’accès à UserInfo est HTTP Auth Header :

 GET /userinfo HTTP/1.1
 Host: oa.dnc.global/userinfo
 Authorization: Bearer SlrqTTP7i88GkKGQWDbPs9RWVAnWHz5e7nxAV32hH

Exemples :

PHP

  1. // Méthode Auth Header
  2.  
  3.     $h = curl_init('https://oa.dnc.global/userinfo');
  4.     curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
  5.     curl_setopt($h, CURLOPT_TIMEOUT, 10);
  6.     curl_setopt($h, CURLOPT_HTTPHEADER, array('Authorization: Bearer ' . $access_token));
  7.  
  8.     $res = curl_exec($h);
  9.     if (!$res)
  10.         exit(curl_error($h));
  11.  
  12.     curl_close($h);
  13.     $res = json_decode($res, true);
  14.  
  15.     echo "UserInfo Response:\n";
  16.     print_r($res);

Télécharger

SPIP

  1. $url = "https://oa.dnc.global/userinfo";
  2. $options = array(
  3.     'methode' => 'GET',
  4.     'datas' => 'Authorization: Bearer ' . $access_token,
  5. );
  6. $resource_response = recuperer_url($url, $options);

Télécharger

Mais on peut également transmettre le jeton d’accès avec la méthode POST. Notez dans l’exemple suivant que le jeton d’accès est fourni sans l’indication ’Bearer’ :
PHP

  1. // Méthode Post
  2.  
  3.     $data2 = array(
  4.         'access_token' => $access_token,
  5.     );
  6.     $h = curl_init($userinfo_endpoint);
  7.     curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
  8.     curl_setopt($h, CURLOPT_TIMEOUT, 10);
  9.     curl_setopt($h, CURLOPT_POST, true);
  10.     curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));     // semble facultatif : curl le fait pour nous?
  11.     curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data2));
  12.     //*/

Télécharger

Réponse du serveur

En cas de succès, le serveur retourne une réponse HTTP 200.

Le corps de la réponse contient un tableau portant les informations suivantes :

index type valeur
status entier code HTTP
headers string Headers de la réponse
page string JSON Array :
La réponse est détaillée ici : Réponse UserInfo.

Note :
- La valeur (string) "null" est forcée pour tous les champs vides ou NULL.
- La spécification indique qu’il n’est pas garanti que la réponse UserInfo corresponde à l’utilisateur identifié par l’élément user_id du ID Token ID. Avant de considérer la réponse UserInfo comme valide, il convient de vérifier que la revendication user_id dans la réponse UserInfo Endpoint correspond exactement à la revendication user_id dans le Token ID.
- Par ailleurs, la spécification impose de vérifier un ID Token dès sa réception. Ceci veut dire que toute requête Userinfo devrait suivre le cycle : demande d’autorisation, validation du jeton ID Token, demande Userinfo, vérification de la concordance des user_id. C’est ce qui est décrit dans les exemples.
- Si la constante de configuration CHECK_CLIENT_IP est réglée à ’true’ (ce qui est fortement conseillé), et que la valeur de l’IP a été fournie lors de l’enregistrement de l’application cliente (ce qui est également conseillé), le contrôleur UserInfo vérifiera que l’IP de l’origine de la requête est conforme. Cela interdit à une application étrangère d’utiliser un jeton d’accès volé.

 

En cas d’échec, le corps de la réponse contient :

index type valeur
page string JSON Array :
error : (string) titre de l’erreur,
error_description : (string) description de l’erreur

La réponse HTTP ainsi que les valeurs de error et error_description sont données par le tableau suivant :

Réponse error titre de l’erreur error_description description de l’erreur Explication
400 invalid_request Only one method may be used to authenticate at a time (Auth header, GET or POST) N’utiliser qu’une seule méthode d’authentification à la fois.
400 invalid_request Malformed auth header La requête de type Auth header est mal formée
400 invalid_request When putting the token in the body, the method must be POST or PUT Si on place le token dans le corps de la requête, la méthode ne peut être que POST ou PUT
400 invalid_request The content type for POST requests must be "application/x-www-form-urlencoded l’IETF spécifie ce type de contenu. NB : tous les serveurs Web ne remplissent pas cette variable _SERVER voir http://tools.ietf.org/html/rfc6750#section-2.2
401 (vide) (vide) La requête ne comporte aucune authentification
401 invalid_token The access token provided is invalid Le jeton ne figure pas dans le tokenStorage du serveur. Très probablement une tentative de violation d’accès.
401 expired_token The access token provided has expired Le jeton a expiré. L’application doit obtenir un nouveau jeton et relancer la requête
401 malformed_token Malformed token (missing "expires"
401 malformed_token Malformed token (missing "client_id")
403 insufficient_scope The request requires higher privileges than provided by the access token L’application cliente n’a pas été inscrite avec le scope openid