Passer au contenu principal
Un soutien pour le mot de passe du propriétaire a été ajouté à /oauth/token. L’utilisation de /oauth/ro comme point de terminaison est déconseillée depuis le 8 juillet 2017. Le point de terminaison /oauth/ro a été utilisé précédemment pour échanger des mots de passe à usage unique (OTP) reçus par l’utilisateur final du service de courriel ou SMS pour un jeton d’ID ou jeton d’accès. Auth0 a mis en place une nouvelle API qui remplace /oauth/ro pour cette utilisation et nous vous recommandons d’effectuer votre migration en utilisant ce nouveau point de terminaison.

​
Caractéristiques affectées

Ce changement vous concerne si vous utilisez le Flux de mot de passe du propriétaire de ressource (parfois appelé Autorisation de mot de passe du propriétaire de ressource) et appelez /oauth/ro directement sans utiliser de bibliothèques d’Auth0 ou de trousses SDK. Les bibliothèques d’Auth0 comme Lock ou Auth0.js ont été mises à jour pour cesser d’utiliser /oauth/ro à l’interne. Si vous utilisez la bibliothèque lock-, vous pouvez désormais utiliser le mode sans mot de passe dans Lock.
Lorsque le jeton d’accès d’un utilisateur basé sur /oauth/ro a expiré, Auth0 force l’utilisateur à se réauthentifier (déconnexion forcée requise), car le jeton d’actualisation /oauth/ro ne peut pas être utilisé pour appeler /oauth/token en vue d’obtenir un nouveau jeton d’accès. Tous les utilisateurs actuellement connectés doivent se connecter à nouveau lors d’une migration /oauth/ro vers /oauth/token.

​
Actions

​
Changements dans les requêtes

Auparavant, la charge utile d’une requête vers /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 version intègre les changements suivants :
  • Le point de terminaison pour exécuter les échanges de jetons est désormais /oauth/token.
  • Le type d’autorisation propre à Auth0 est utilisé pour authentifier les utilisateurs à partir d’une connexion (ou d’une partition) spécifique.
  • Auth0 prend en charge les permissions OIDC standard, ainsi que les permissions que vous avez définies dans votre API personnalisée.
  • Une permission qui ne s’inscrit pas dans l’une de ces catégories, comme favorite_color ci-dessus, n’est plus une permission valide.
  • Le paramètre device a été retiré.
  • Le paramètre audience est facultatif.
Voici un exemple de la charge utile 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’autorisation est indiqué ici en tant que password-realm (partition du mot de passe) plutôt que le password (mot de passe) standard.
  • Les paramètres client_id, username, et password sont inchangés.
  • La realm (partition) est incluse car nous utilisons le type d’autorisation Partition de mot de passe, qui remplace le paramètre connection (connexion) des anciennes requêtes.
  • Le paramètre scope est sensiblement le même, mais il n’accepte pas les valeurs non OIDC.
  • Le paramètre audience peut être ajouté et indique le type d’ de l’API auquel le jeton est destiné.

​
Changements dans les réponses

Les réponses provenant de /oauth/ro avait un format similaire à celui-ci : 
{
  "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 spécifiée par le paramètre audience utilise RS256 comme algorithme de signature) et éventuellement l’API personnalisée si elle a été spécifiée.
  • Le jeton d’ID sera signé de force à l’aide de l’algorithme RS256 si un client public en fait la demande.
  • Un jeton d’actualisation sera renvoyé seulement si la permission offline_access a été octroyée et que l’option Autoriser l’accès hors ligne est activée dans l’API.
Voici un exemple de réponse conforme à OIDC provenant de /oauth/token : 
{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJ..."
}

​
Vérifier la migration

  1. Une fois que vous avez migré votre base de code et que vous avez la certitude que vos applications ne sont pas en train d’appeler le point de terminaison, allez dans Dashboard > Paramètres du locataire > Avancés.
  2. Faites défiler vers le bas jusqu’à Migrations et désactivez Legacy /oauth/ro Endpoint (Point de terminaison /oauth/ro existant). Ce commutateur permet de désactiver le point de terminaison obsolète pour votre locataire, et empêche ainsi toute utilisation ultérieure.
Si la désactivation du commutateur entraîne des échecs de connexion, c’est le signe que vous n’avez pas encore supprimé toutes les instances de code hérité de vos applications. Une fois que les migrations ont bien été effectuées dans les environnements de production, le commutateur peut être désactivé et ignoré, afin de s’assurer que les fonctionnalités obsolètes ne peuvent plus être utilisées.
⌘I