Flux implicite avec OIDC

Découvrez comment le pipeline conforme à OIDC d’Auth0 modifie le comportement du flux implicite et met à jour les applications existantes sans perturber la gestion des jetons.

Traditionnellement, le flux implicite était utilisé par les applications qui n’étaient pas en mesure de stocker des secrets de façon sécuritaire. L’utilisation de ce flux n’est plus considérée comme une pratique exemplaire pour demander des jetons d’accès ; les nouvelles mises en œuvre devraient plutôt utiliser le flux de code d’autorisation avec PKCE. Toutefois, lorsqu’il est utilisé avec le mode de réponse Form Post, le flux implicite offre bel et bien un flux de travail simplifié si l’application n’a besoin que d’un jeton d’ID pour authentifier l’utilisateur; dans ce cas, il serait utilisé dans le cadre du flux hybride.

Les jetons d’actualisation ne seront plus renvoyés lors de l’utilisation du flux implicite pour l’authentification.

De plus, le pipeline conforme à OIDC a une incidence sur le flux implicite dans les domaines suivants : la requête d’authentification, la réponse d’authentification, la structure du jeton d’ID et la structure du jeton d’accès.

​

Requête d’authentification

​

version antérieure

GET /authorize?
    response_type=token
    &scope=openid email favorite_color offline_access
    &client_id=123
    &state=af0ifjsldkj
    &redirect_uri=https://app.example.com
    &device=my-device-name

Le paramètre device n’est nécessaire que si vous demandez un jeton d’actualisation en incluant la portée offline_access. Pour en savoir plus, consultez Jetons d’actualisation.

​

conforme à OIDC

GET /authorize?
    response_type=token id_token
    &scope=openid email
    &client_id=123
    &state=af0ifjsldkj
    &nonce=jxdlsjfi0fa
    &redirect_uri=https://app.example.com
    &audience=https://api.example.com

• response_type indique que nous voulons recevoir à la fois un jeton d’accès et un jeton d’ID.
• Les jetons d’actualisation ne sont pas pris en charge dans le flux implicite. Utilisez plutôt prompt=none. Pour en savoir plus, consultez Configurer l’authentification silencieuse.
• favorite_color n’est plus un scope valide.
• audience est facultatif.
• nonce doit être une chaîne aléatoire sécurisée sur le plan cryptographique. Pour en savoir plus, consultez Atténuer les attaques par rejeu lors de l’utilisation du flux implicite.

​

Réponse d’authentification

​

Version antérieure

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=SlAV32hkKG
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &refresh_token=8xLOxBtZp8
    &token_type=Bearer

• Le jeton d’accès renvoyé est valide pour appeler le point de terminaison /userinfo.
• Un jeton d’actualisation n’est renvoyé que si un paramètre device a été transmis et si la portée offline_access a été demandée.

​

Conforme à OIDC

HTTP/1.1 302 Found
Location: https://app.example.com/#
    access_token=eyJ...
    &expires_in=86400
    &state=af0ifjsldk
    &id_token=eyJ...
    &token_type=Bearer

• Le jeton d’accès renvoyé est valide pour appeler le point de terminaison /userinfo (à condition que l’API spécifiée par le paramètre audience utilise RS256 comme algorithme de signature) et, au besoin, le serveur de ressources spécifié par le paramètre audience.
• Si vous utilisez response_type=id_token, Auth0 renverra uniquement un jeton d’ID. Les jetons d’actualisation ne sont pas autorisés dans l’Implicit grant. Utilisez plutôt prompt=none.

​

Structure du jeton d’ID

​

Version antérieure

​

Conforme à OIDC

• Le claim favorite_color doit être muni d’un espace de noms et ajouté au moyen d’une rule. Pour en savoir plus, consultez Créer des custom claims avec espace de noms.
• Après avoir validé le jeton d’ID, l’application doit valider le nonce afin d’atténuer les attaques par rejeu.

​

Structure du jeton d’accès (facultatif)

​

version antérieure

HTTP

SlAV32hkKG

Le jeton d’accès renvoyé est opaque et n’est valide que pour effectuer une requête au point de terminaison /userinfo.

​

Conforme à OIDC

• Le jeton d’accès renvoyé est un JWT valide pour appeler le endpoint /userinfo (à condition que l’API spécifiée par le paramètre audience utilise RS256 comme algorithme de signature), ainsi que le serveur de ressources spécifié par le paramètre audience.
• Un jeton d’accès opaque peut tout de même être renvoyé si /userinfo est la seule audience spécifiée.

​

En savoir plus

• Jetons d’accès avec OIDC
• API externes avec OIDC
• Flux de code d’autorisation avec OIDC
• Flux des informations d’identification du client avec OIDC
• Délégation avec OIDC
• Jetons d’actualisation avec OIDC