Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > API OpenID Connect : Point d’extrémité de jeton (Token Endpoint)

API OpenID Connect : Point d’extrémité de jeton (Token Endpoint)

Pour obtenir les jetons, une application cliente s’adresse au point d’extrémité token avec le code obtenu dans la phase d’autorisation. Dans le cadre du protocole OpenID Connect, l’appel au contrôleur Token suit la demande d’authentification.

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.

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

La demande ne doit être effectuée que par la méthode POST.

Pour l’authentification de l’application cliente auprès du serveur d’autorisation, OAuthSD impose la méthode client_secret_basic. L’authentification est donc 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.

Les paramètres suivants doivent être postés :
- grant_type : Type de flux d’autorisation, doit être "authorization_code".
- code : le code d’autorisation reçu.
- redirect_uri : l’adresse de retour à l’application cliente.

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).