Passer au contenu principal
La prise en charge du mot de passe du a été ajoutée à /oauth/token. L’utilisation du point de terminaison /oauth/ro a été déclarée obsolète le 08 juillet 2017. Le point de terminaison /oauth/ro était auparavant utilisé pour échanger un mot de passe à usage unique (OTP) reçu par l’utilisateur final par courriel ou SMS contre un et un . Auth0 a mis en place une nouvelle API qui remplace /oauth/ro pour ce cas d’utilisation, et nous vous recommandons de migrer vers le nouveau point de terminaison.

​
Fonctionnalités concernées

Ce changement vous concerne si vous utilisez le flux de mot de passe du propriétaire de la ressource (parfois appelé Resource Owner Password Grant ou ROPG) et appelez directement /oauth/ro sans utiliser de bibliothèques Auth0 ni de SDK. Les bibliothèques Auth0 comme Lock ou Auth0.js ont été mises à jour pour ne plus utiliser /oauth/ro en interne. Si vous utilisez la bibliothèque lock-, vous pouvez désormais utiliser le mode Passwordless dans Lock à la place.
Lorsqu’un jeton d’accès basé sur /oauth/ro d’un utilisateur expire, Auth0 l’oblige à se réauthentifier (déconnexion forcée requise), car le jeton d’actualisation /oauth/ro ne peut pas être utilisé pour appeler /oauth/token afin d’obtenir un nouveau jeton d’accès. Tous les utilisateurs actuellement connectés doivent se reconnecter lors d’une migration de /oauth/ro vers /oauth/token.

​
Actions

​
Modifications des requêtes

Auparavant, le payload d’une requête à /oauth/ro ressemblait à ceci : 
{
  "grant_type": "password",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w", 
  "connection": "my-database-connection",
  "scope": "openid email favorite_color offline_access",
  "device": "my-device-name"
}
La nouvelle implémentation comprend les changements suivants :
  • Le point de terminaison pour effectuer des échanges de jetons est maintenant /oauth/token.
  • Le type d’octroi propre à Auth0 est utilisé pour authentifier les utilisateurs à partir d’une connexion donnée (ou d’un realm).
  • Auth0 prend en charge les scopes OIDC standard, ainsi que les scopes que vous avez définis dans votre API personnalisée.
  • Un scope qui n’entre dans aucune de ces catégories, comme favorite_color ci-dessus, n’est plus valide.
  • Le paramètre device est supprimé.
  • Le paramètre audience est facultatif.
Voici un exemple de payload d’une requête vers /oauth/token : 
{
  "grant_type": "http://auth0.com/oauth/grant-type/password-realm",
  "client_id": "123",
  "username": "alice",
  "password": "A3ddj3w",
  "realm": "my-database-connection",
  "scope": "openid email offline_access",
  "audience": "https://api.example.com"
}
  • Le type d’octroi est spécifié ici comme password-realm, plutôt que le password standard.
  • Les paramètres client_id, username et password demeurent inchangés.
  • Le realm est inclus parce que nous utilisons le type d’octroi Password Realm et remplace le paramètre connection des appels précédents.
  • Le paramètre scope est essentiellement le même, mais n’accepte pas de valeurs non OIDC.
  • Le paramètre audience peut être ajouté pour indiquer l’API à laquelle le jeton sera destiné.

​
Changements dans les réponses

Les réponses de /oauth/ro avaient un format semblable au suivant : 
{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJ..."
}
  • Le jeton d’accès renvoyé est valide pour appeler le point de terminaison /userinfo (à condition que l’API précisée par le paramètre audience utilise RS256 comme ) et éventuellement l’API personnalisée, si elle a été précisée.
  • L’ID Token sera obligatoirement signé avec RS256 s’il est demandé par une .
  • Un sera renvoyé seulement si le scope offline_access a été accordé et que l’API a l’option Allow offline access activée.
Voici un exemple de réponse conforme à OIDC pour /oauth/token : 
{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJ..."
}

​
Vérifier la migration

  1. Une fois votre base de code migrée et après avoir confirmé que vos applications n’appellent plus le point de terminaison, accédez à Auth0 Dashboard > Paramètres du locataire > Avancé.
  2. Faites défiler la page jusqu’à Migrations et désactivez ancien /oauth/ro point de terminaison. Désactiver ce commutateur a pour effet de désactiver le point de terminaison obsolète pour votre locataire et d’empêcher son utilisation.
Si la désactivation de ce commutateur entraîne des échecs de connexion, cela indique que vous n’avez pas encore complètement supprimé toutes les occurrences de code ancien de vos applications. Une fois les migrations effectuées avec succès dans les environnements de production, vous pouvez désactiver ce commutateur et le laisser désactivé afin de vous assurer que les fonctionnalités obsolètes ne peuvent plus être utilisées.