Passer au contenu principal
Le flux de code d’autorisation est utilisé par les applications côté serveur capables de stocker des secrets de façon sécurisée, ou par les applications natives au moyen du flux de code d’autorisation avec PKCE. Le pipeline conforme à OIDC a une incidence sur le flux de code d’autorisation dans les domaines suivants :
  • Requête d’authentification
  • Réponse d’authentification
  • Requête d’échange de code
  • Réponse d’échange de code
  • structure
  • structure

​
Requête d’authentification

​
Version héritée

GET /authorize?
    response_type=code
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com/callback
    &device=my-device-name
Le paramètre device n’est requis que si vous demandez un en spécifiant le scope offline_access. Pour en savoir plus, consultez Refresh Tokens.

​
Conforme à OIDC

GET /authorize?
    response_type=code
    &scope=openid email offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com/callback
    &audience=https://api.example.com
  • favorite_color n’est plus une valeur de scope valide.
  • Le paramètre device a été supprimé.
  • Le paramètre audience est facultatif.

​
Réponse d’authentification

La réponse d’Auth0 est identique dans les deux pipelines : 
HTTP/1.1 302 Found
Location: https://app.example.com/callback?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj

​
Requête d’échange de code - flux de code d’autorisation

Un code d’autorisation peut être échangé de la même manière dans les deux pipelines :

​
Requête d’échange de code - Flux de code d’autorisation avec PKCE

Un code d’autorisation peut être échangé de la même façon dans les deux pipelines :

​
Réponse de l’échange de code

​
Version héritée

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • Le Jeton d’accès renvoyé n’est valide que pour appeler le point de terminaison /userinfo.
  • Un Jeton d’actualisation n’est renvoyé que si un paramètre device a été transmis et que le scope offline_access a été demandé.

​
Conforme à OIDC

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "access_token": "eyJ...",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJ..."
}
  • Le jeton d’accès renvoyé est valide pour appeler, au besoin, l’API spécifiée dans le paramètre audience et le point de terminaison /userinfo (à condition que l’API utilise RS256 comme algorithme de signature et que openid soit utilisé comme paramètre scope). Si vous n’implémentez pas votre propre (API), vous pouvez utiliser https://{$account.namespace}/userinfo comme paramètre audience, ce qui renverra un jeton d’accès opaque.
  • Un jeton d’actualisation n’est renvoyé que si le scope offline_access a été accordé.

​
Structure du jeton d’identité

​
Version héritée

​
Conforme à OIDC

Le claim favorite_color doit être ajouté au moyen d’une Action Auth0. Pour en savoir plus, consultez Créer des claims personnalisés.

​
Structure du jeton d’accès (facultative)

​
Version héritée

HTTP
SlAV32hkKG
Le jeton d’accès renvoyé est opaque et n’est valide que pour appeler le point de terminaison /userinfo.

​
Conforme à OIDC

Le jeton d’accès renvoyé est valide pour appeler, au besoin, l’API indiquée dans le paramètre audience ainsi que le point de terminaison /userinfo (à condition que l’API utilise RS256 comme et que openid soit utilisé comme paramètre scope). Si vous n’implémentez pas votre propre serveur de ressources (API), vous pouvez utiliser https://{$account.namespace}/userinfo comme paramètre audience, ce qui renverra un jeton d’accès opaque.

​
En savoir plus