- Suivre des renseignements sur l’appareil, comme son nom ou le lieu de connexion
- Stocker des indicateurs au niveau du jeton, par exemple
user_accepted_termsousession_type - Partager l’état entre plusieurs Actions dans le même flux
- Alimenter une logique conditionnelle pour l’émission ou la révocation de jetons
- Des pipelines d’audit et d’analyse qui doivent tenir compte des données contextuelles de l’utilisateur
Flux pris en charge
- Flux du code d’autorisation
- Grant de mot de passe du propriétaire de la ressource
- Grant d’autorisation de l’appareil
- Flux de connexions fédérées
- Authentification en canal secondaire initiée par le client (CIBA)
- Clés d’accès natives
- Échange de jeton d’actualisation
Vous pouvez définir les métadonnées du jeton d’actualisation dans n’importe lequel des flux pris en charge ci-dessus. Cependant, les métadonnées existantes peuvent uniquement être lues au moyen de l’objet
event.refresh_token.metadata dans les scénarios d’échange de jeton d’actualisation où event.refresh_token existe. À la connexion initiale, event.refresh_token n’existe pas; vous pouvez donc seulement définir des métadonnées, sans pouvoir les lire. Lors d’un échange de jeton d’actualisation, vous pouvez à la fois lire les métadonnées existantes et définir de nouvelles valeurs.Limitations
- Les métadonnées du jeton d’actualisation sont limitées à un maximum de 25 entrées
- Chaque clé et chaque valeur doivent contenir au plus 255 caractères
- Les clés de métadonnées peuvent uniquement contenir des lettres, des chiffres, des traits de soulignement ou des traits d’union