Skip to main content
Une fois l’agent associé à un client, les jetons émis à ce client portent l’identité de l’agent à des fins d’attribution et de traçabilité. La façon dont l’identité de l’agent apparaît dans le jeton dépend du type d’autorisation :
  • Flux des identifiants client : l’agent est le sujet. Son identité apparaît dans la demande personnalisée sub de premier niveau.
  • Flux de connexion standard : l’utilisateur est le sujet. L’identité de l’agent apparaît dans une demande personnalisée act à un seul niveau.
  • Échange de jetons On-Behalf-Of (OBO) : l’utilisateur demeure le sujet. L’identité de l’agent apparaît dans la demande personnalisée act, accompagnée d’une demande personnalisée act imbriquée qui indique le client d’origine.
Auth0 ne prend pas en charge le type d’autorisation jwt_bearer pour les clients liés à un agent.
Auth0 adopte également l’ébauche OAuth Actor Profile for Delegation, qui introduit les demandes personnalisées sub_profile et client_profile afin d’identifier explicitement le type d’entité à chaque position du jeton.

​
Demandes personnalisées du sujet de l’agent

Les demandes personnalisées sub_profile et client_profile précisent le type d’entité dans les jetons émis par les clients liés à un agent : Vous devez configurer votre serveur de ressources pour qu’il reçoive les demandes personnalisées sub_profile et client_profile dans les jetons émis. Partout où l’identifiant d’un agent apparaît dans une demande personnalisée (sub de premier niveau ou act.sub), il s’agit de l’external_agent_id de l’agent si celui-ci a été défini à la création; sinon, il s’agit de l’agent_id.

​
Configurer le serveur de ressources pour recevoir les demandes de sujet de l’agent

Pour recevoir les demandes sub_profile et client_profile, définissez agent_subject_claims: 'auth0-v1' sur le serveur de ressources cible. Cette option doit être activée individuellement pour chaque serveur de ressources.
La demande personnalisée sub_profile introduit un type d’entité formel dans le jeton. Les services qui reçoivent des jetons ne devraient pas présumer que sub_profile vaudra toujours user. Si sub_profile est absent (l’option n’est pas activée pour le serveur de ressources), le comportement actuel demeure inchangé.Vérifiez la façon dont sub est analysé dans les services en aval avant d’activer l’option. Les services qui valident ou analysent le format de la demande personnalisée sub devront peut-être être mis à jour pour traiter ai_agent comme un type d’entité valide dans le cas des octrois par information d’identification du client.

​
Flux de connexion standard

Un client lié à un agent peut exécuter un flux de connexion standard à l’aide de l’octroi par code d’autorisation, implicite, CIBA, par appareil, MFA, par mot de passe, par clé d’identification ou par jeton d’actualisation. Le sujet demeure l’utilisateur. L’identité de l’agent n’apparaît pas dans la demande personnalisée sub de premier niveau. À la place, une demande personnalisée act à un seul niveau est ajoutée afin que l’agent puisse être identifié dans le jeton. Dans l’exemple suivant, un client lié à un agent exécute un flux de connexion standard et émet un jeton comportant les demandes de sujet d’agent suivantes :
  • sub : l’identifiant de l’utilisateur
  • sub_profile : user
  • client_profile : ai_agent, qui indique que le client est lié à un agent
  • act : une demande d’acteur à un seul niveau qui identifie l’agent ("sub": "agt_1a2b3c", "sub_profile": "ai_agent")

​
Flux des identifiants client

Un client de communication entre machines (M2M) lié à un agent exécute un flux des identifiants client. L’agent est le sujet et s’authentifie en son propre nom; aucun utilisateur n’intervient. Dans l’exemple suivant, un client M2M lié à un agent exécute un flux des identifiants client et émet un jeton comportant les demandes de sujet d’agent suivantes :
  • sub : l’external_agent_id de l’agent s’il en a été défini un à la création, sinon l’agent_id
  • sub_profile : ai_agent
  • client_profile : service ai_agent, représentant le client M2M lié à l’agent

​
Échange de jetons On-Behalf-Of (OBO)

Dans l’échange de jetons OBO, un utilisateur s’authentifie et reçoit un jeton d’accès dont le public est le serveur de ressources de l’agent. Le client lié à l’agent échange ensuite ce jeton contre un jeton délégué au moyen de l’échange de jetons On-Behalf-Of. L’utilisateur demeure le sujet tout au long du processus. L’agent est identifié comme l’acteur dans la demande personnalisée act. Avant l’échange de jetons, l’utilisateur s’authentifie au moyen d’une application de navigateur et reçoit un jeton d’accès :
  • sub : l’identifiant de l’utilisateur
  • sub_profile : user
  • client_profile : identifie le client d’origine comme un browser_app
  • aud : le serveur de ressources de l’agent
Le client lié à l’agent échange le jeton de l’utilisateur au moyen de l’échange de jetons OBO :
  • sub : l’identifiant de l’utilisateur (inchangé)
  • sub_profile : user (inchangé)
  • client_profile : service ai_agent, qui représente le client lié à l’agent
  • aud : le nouveau serveur de ressources
  • act : l’acteur immédiat est l’agent, avec un act imbriqué qui indique le client d’origine ayant amorcé le flux. La profondeur maximale de délégation est de 5 sauts, soit 4 niveaux de act imbriqués.
L’échange de jetons prend actuellement en charge l’OBO uniquement lorsque le sujet du jeton entrant est un utilisateur. L’émission de jetons dans lesquels un agent ou un client est lui-même le sujet de premier niveau d’un échange OBO n’est pas encore prise en charge.
Les jetons d’actualisation ne sont pas pris en charge pour l’échange de jetons OBO. Pour en apprendre davantage sur la configuration et les limites, faites la lecture de Échange de jetons On-Behalf-Of.

​
Prochaines étapes