Configurer les applications pour MRRT
Pour utiliser les multi-ressources (MRRT), configurez les politiques de jeton d’actualisation de votre application à l’aide de la Management API d’Auth0. Ces politiques préciseront quelles API et quelles portées l’application est autorisée à demander lors d’un échange de jeton d’actualisation. Vous pouvez définir des politiques MRRT dans la propriétérefresh_token.policies de l’application.
Les propriétés audience et scope doivent correspondre à une application existante dans votre tenant, sinon l’échange de jeton d’actualisation les ignorera sans avertissement.
Vous utilisez Auth0 CLI? Si ce n’est pas déjà fait, configurez et authentifiez votre session CLI avant d’exécuter cette commande.
Implement jeton d’actualisation multiressource
Une fois le jeton d’actualisation de votre application configuré avec des politiques MRRT, vous pouvez commencer à échanger un seul jeton d’actualisation contre des pour plusieurs API. Pour ce faire, votre application doit amorcer un flux de connexion à l’aide soit du Flux de code d’autorisation, soit de l’Octroi de mot de passe du propriétaire de la ressource.Étape 1 : S’authentifier et demander un jeton d’actualisation
Pour recevoir un jeton d’actualisation, incluez la portéeoffline_access lorsque vous lancez la requête d’authentification. Pour en savoir plus, consultez Obtenir des jetons d’actualisation.
Si vous ne recevez pas de jeton d’actualisation, vérifiez que :
- L’API a l’option Allow Offline Access activée dans ses paramètres.
offline_accessest inclus dans la portée.- La valeur
audienceutilisée dans la requête correspond à une API configurée dans votre tenant.
Étape 2 : Échanger le jeton d’actualisation pour accéder à une autre API
Une fois le jeton d’actualisation émis, vous pouvez demander des jetons d’accès pour n’importe quelle API et toute portée définies dans l’authentification initiale et dans la politique MRRT. Par exemple : Pour en savoir plus, consultez Utiliser les jetons d’actualisation. Si vous utilisez le SDK Auth0 Swift, vous pouvez échanger le jeton d’actualisation à l’aide du code suivant :Étape 3 : Appeler l’API à l’aide du jeton d’accès
Utilisez le jeton d’accès pour faire une requête à l’API sécurisée au moyen du schéma d’autorisation HTTP Bearer. Pour en savoir plus, consultez Use Access Tokens.Vous pouvez décoder le jeton d’accès sur jwt.io pour vérifier ce qui suit :
- Le champ
audcorrespond à l’API demandée. (par exemple : https://billing.example.com). - Le champ
scopeinclut uniquement les valeurs autorisées.
Utiliser le jeton d’actualisation multi-ressource avec Actions
L’utilisation de MRRT avec Actions vous permet de configurer une prise de décision dynamique en fonction des politiques MRRT de l’application. À cette fin, les Actions post-login incluent l’objetevent.client.refresh_token.policies, qui fournit des renseignements pertinents, notamment l’ et la portée.
Vous pouvez utiliser l’objet event.client.refresh_token.policies pour évaluer l’audience et la portée de l’application au moment d’émettre ou d’échanger un jeton d’actualisation, et pour assurer un contrôle précis de l’accès à l’API et des portées.
Logique d’évaluation
Le MRRT agit comme une extension de l’authentification d’origine, et non comme un remplacement. Lors de l’échange d’un jeton d’actualisation, Auth0 évalue la requête d’échange selon la logique suivante :- Si le paramètre
audienceest omis, Auth0 renvoie un jeton d’accès avec l’audience d’origine et toutes les portées supplémentaires configurées dans la politique MRRT. - Si un nouveau paramètre
audienceest précisé, Auth0 vérifie que l’audience est incluse dans la politique MRRT et renvoie un jeton d’accès pour la nouvelle audience avec les portées configurées. - Si le paramètre
scopeest omis, Auth0 combine toutes les portées autorisées de la requête d’origine et de la politique MRRT. - Si un nouveau paramètre
scopeest précisé, Auth0 valide les portées demandées et renvoie un jeton d’accès avec les portées incluses dans la politique MRRT. Les portées demandées invalides ou non autorisées sont ignorées sans avertissement. - Si le paramètre
audienceest identique à celui de la requête d’origine, Auth0 applique la politique MRRT et renvoie un jeton d’accès pour cette audience avec toutes les portées configurées par le MRRT ainsi que les portées de l’authentification d’origine.