Point d’extrémité de jeton (Token Endpoint)
https://oa.dnc.global/token
Le point d’extrémité de jeton est le point d’extrémité sur le serveur d’autorisation auquel s’adresse l’application cliente avec le code d’autorisation.
Forme de la demande de jeton d’accès dans le cadre du flux Authorization Code Grant
La demande ne doit être effectuée que par la méthode POST.
Les paramètres suivants doivent être postés :
grant_type : (OBLIGATOIRE) Type de flux d’autorisation, doit être "authorization_code".
code : (OBLIGATOIRE) le code d’autorisation reçu.
redirect_uri : (OPTIONNEL) l’adresse de retour à l’application cliente. Si cette valeur est fournie, elle doit correspondre à l’une des valeurs inscrites pour le client. Si cette valeur est omise, la valeur unique inscrite pour le client sera utilisée.
Pour l’authentification de l’application cliente auprès du serveur d’autorisation, OAuthSD accepte les méthodes ’client_secret_basic’ et ’client_secret_post’ [1].
Authentification du client par ’client_secret_basic’
L’authentification est effectuée en utilisant l’authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]).
Exemple de construction de l’entête Authorize avec PHP cURL :
PHP
- // Token request
- 'grant_type' => 'authorization_code',
- 'code' => $code,
- );
- //curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
Authentification du client par ’client_secret_post’
Les identifiants client_id et client_secret qui ont été définis lors de l’inscription de l’application cliente sur le serveur sont passés dans le corps de la requête.
Exemple avec PHP cUrl :
PHP
- // Token request
- 'client_id' => $client_id,
- 'client_secret' => $client_secret,
- 'grant_type' => 'authorization_code',
- 'code' => $code,
- );
- //curl_setopt($h, CURLOPT_SSL_VERIFYPEER, false);
Autres flux
Notons que OAuth 2.0 définit des flux effectuant un appel direct au contrôleur Token, voir : différents type de flux.
Notons également que le flux implicite défini dans le cadre d’OpenID Connect obtient directement les jetons du contrôleur Authorize.
Certains auteurs définissent dans le cadre d’OAuth 2.0 un flux "Refresh Token Grant" s’adressant au point d’extrémité de jeton. Il ne s’agit pas à proprement parler d’un flux puisque, prolongeant un flux d’autorisation établi précédemment, il ne peut exister de façon autonome et donc contredit la nature REST de l’API. Voir : Rafraîchir (actualiser) un jeton d’accès.
Réponse du serveur
En cas de succès, le serveur retourne une réponse HTTP 200. Le corps de la réponse contient :
| index | type | valeur |
|---|---|---|
| page | JSON array | access_token : (string) jeton d’accès OAuth 2.0 expires_in : (long) durée de vie en secondes token_type : (string) "Bearer" scope : (string) "openid ... " id_token : (string) jeton d’identification (JWT) |
Le Header comporte, comme il se doit, la directive ’Cache-Control : no-cache, no-store’.
En cas d’échec, le corps de la réponse contient :
| index | type | valeur |
|---|---|---|
| page | JSON Array | error : titre de l’erreur, error_description : 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 |
| 405 | invalid_request | The request method must be POST when requesting an access token | La méthode de la demande doit être POST lorsque vous demandez un jeton d’accès. Notez que le Header contient ’Allow : POST’ |
| 400 | invalid_request | The grant type was not specified in the request | Le type d’autorisation n’a pas été spécifié dans la demande |
| 400 | unsupported_grant_type | Grant type "X" not supported | Le Type d’autorisation "X" n’est pas supporté. |
| 400 | invalid_grant | Authorization code doesn\’t exist or is invalid for the client | Le code d’autorisation n’existe pas ou est invalide pour le client. Cette situation peut résulter du fait que le code a déjà été utilisé pour une demande de jeton. |
| 400 | unauthorized_client | The grant type is unauthorized for this client_id | Le type d’autorisation n’est pas autorisé pour ce client_id |
| 400 | invalid_scope | The scope requested is invalid for this request | La portée d’autorisation demandée est invalide pour cette demande |
| 400 | invalid_scope | The scope requested is invalid for this client | La portée d’autorisation demandée est valide pour ce client |
| 400 | invalid_scope | An unsupported scope was requested | La portée d’autorisation demandée n’est pas supportée |
Demande du jeton de rafraîchissement
OpenID Connect ne retourne un jeton de rafraîchissement (Refresh Token), conjointement au jeton d’accès, que si le scope "offline_access" a été inclus dans la requête et accepté, ce qui ne se produira qu’avec le flux d’Autorisation via un code (Authorization Code Grant).
RSS 2.0