Demande de jeton (Token request)

Qu’est-ce qu’une demande de jeton (token request) ?

Dans OAuth 2.0 et OpenID Connect (OIDC) , une demande de jeton (token request) est une demande au Serveur d'autorisation (Authorization server) (ou OpenID Provider (OP) en OIDC) pour échanger des informations d’identification (par exemple, code d’autorisation, jeton d’actualisation) contre un ensemble de jetons. L’ensemble de jetons inclut généralement un ou plusieurs des éléments suivants :

• Jeton d'accès (Access token) : Un jeton qui accorde l’accès aux ressources protégées.
• Jeton ID (ID token) : Un jeton qui contient des informations de l’utilisateur (spécifique à OIDC).
• Jeton d'actualisation (Refresh token) : Un jeton qui peut être utilisé pour obtenir un nouveau jeton d’accès sans interaction de l’utilisateur.

Selon le type de subvention (grant type) utilisé, la demande peut inclure différents paramètres et renvoyer différents jetons.

Par exemple, dans le Flux d'informations d'identification client (Client credentials flow) , le Client demande directement un Jeton d'accès (Access token) avec des informations d’identification de client. Voici un exemple non normatif de la demande de jeton :

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
  &client_id=client-id
  &client_secret=client-secret
  &scope=read

Si la demande est réussie, le serveur d’autorisation répond avec un jeton d’accès :

HTTP/1.1 200 OK
Content-Type: application/json

{
  "access_token": "eyJhbGci...zHg",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read"
}

Comment fonctionne une demande de jeton (token request) ?

Comme le montre l’exemple ci-dessus, la demande de jeton (token request) elle-même est simple. Le client envoie une requête HTTP à l’endpoint de jeton du serveur d’autorisation avec les paramètres nécessaires. Le serveur d’autorisation valide la demande, la traite, et renvoie les jetons dans la réponse.

Cependant, selon le type de subvention (flow) spécifié utilisé, la demande de jeton peut nécessiter plus de préparation.

Flux de code d’autorisation (Authorization code flow)

Dans le Flux du code d'autorisation (Authorization code flow) , le client obtient d’abord un code d’autorisation en initiant une Demande d'autorisation (Authorization request) (ou Requête d'authentification (Authentication request) en OIDC) avec le serveur d’autorisation. Une fois que l’utilisateur accorde la permission, le client échange le code d’autorisation pour un jeton d’accès et éventuellement un jeton d’actualisation via la demande de jeton.

Voici un diagramme de séquence simplifié du flux de code d’autorisation :

Flux d’identification du client (Client credentials flow)

Comme le montre l’exemple de la première section, le Flux d'informations d'identification client (Client credentials flow) est bien plus simple. Le client demande directement un jeton d’accès avec ses informations d’identification de client. Le serveur d’autorisation valide les informations d’identification du client et émet un jeton d’accès si cela réussit.

Voici un diagramme de séquence non normatif du flux d’identification du client :

Jeton d’actualisation (Refresh token)

Dans certains types de subventions, le client peut également demander Accès hors ligne (Offline access) en incluant le champ offline_access dans la demande d’autorisation. Si cela est accordé, le serveur d’autorisation émet un jeton d’actualisation accompagné du jeton d’accès. Le client peut utiliser le jeton d’actualisation pour obtenir un nouveau jeton d’accès via la demande de jeton sans interaction de l’utilisateur.

Voici un exemple non normatif de l’utilisation d’un jeton d’actualisation pour obtenir un nouveau jeton d’accès :

POST /token HTTP/1.1
Host: authorization-server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
  &refresh_token=refresh-token
  &client_id=client-id
  &client_secret=client-secret

---

D’autres types de subventions peuvent également impliquer des demandes de jeton, mais l’idée de base reste la même.

Paramètres clés dans une demande de jeton

Voici quelques paramètres clés qui sont couramment utilisés dans une demande de jeton :

• grant_type : Le type de subvention demandée. Les valeurs courantes incluent authorization_code, client_credentials, refresh_token, etc.
• client_id : L’identifiant du client émis par le serveur d’autorisation.
• client_secret : Le secret du client émis par le serveur d’autorisation (pour les clients confidentiels).
• code : Le code d’autorisation obtenu auprès du serveur d’autorisation (pour le flux de code d’autorisation).
• refresh_token : Le jeton d’actualisation obtenu auprès du serveur d’autorisation (pour rafraîchir les jetons d’accès).
• scope : Les périmètres (permissions) demandés pour le jeton d’accès.
• redirect_uri : L’URI où le serveur d’autorisation envoie la réponse (pour le flux de code d’autorisation).
• code_verifier : Le vérificateur de code utilisé dans l’extension Clé de preuve pour l'échange de code (Proof Key for Code Exchange, PKCE) (pour le flux de code d’autorisation).

Les paramètres réels et leurs valeurs dépendent du type de subvention et des exigences spécifiques de l’application. Avant de faire une demande de jeton, vous devriez vous référer à la liste complète des paramètres pour le type de subvention spécifique que vous utilisez.

Voir aussi

• OAuth 2.0
• OpenID Connect (OIDC)
• Demande d'autorisation (Authorization request)
• Requête d'authentification (Authentication request)