À propos de l'authentification unique

S'APPLIQUE À : SDK v4

L'authentification unique (SSO) permet de partager l'accès aux ressources entre des applications indépendantes. Par exemple, un utilisateur peut se connecter à un service dans un bot racine, et ce dernier peut partager le jeton d'accès avec un bot de compétence. Actuellement, seul le fournisseur d'identité Microsoft Entra ID est pris en charge.

L’authentification unique s’applique aux scénarios suivants :

• Un bot racine et un ou plusieurs bots de compétences. L'utilisateur se connecte à partir du bot racine. Le bot appelle alors plusieurs compétences au nom de l'utilisateur.
• Contrôle Chat Web incorporé sur un site web. L'utilisateur se connecte à partir du site web. Le site web appelle ensuite un bot ou une compétence pour le compte de l’utilisateur.

L’authentification unique offre les avantages suivants :

• L'utilisateur n'a pas besoin de se connecter plusieurs fois.
• Le bot ou le site web racine n'a pas besoin de connaître les autorisations de l'utilisateur.

Interaction des éléments intervenant dans l’authentification unique

Les schémas suivants montrent, de manière chronologique, les interactions entre les différents éléments intervenant dans l’authentification unique.

• Le diagramme suivant illustre le flux d'un bot racine.

  

• Le diagramme suivant illustre le flux, et le flux de secours, pour un contrôle de Chat Web.

  

  Si l'échange de jetons échoue, la secours consiste à inviter l'utilisateur à se connecter. De telles défaillances peuvent se produire lorsque des autorisations supplémentaires sont requises ou que le jeton est destiné au mauvais service.

Analysons le flux.

1. Le client commence une conversation avec le bot, ce qui déclenche un scénario d’authentification OAuth.

2. Le bot renvoie une carte OAuth au client.

3. Le client intercepte la carte OAuth avant de l’afficher pour l’utilisateur et vérifie si elle contient une propriété TokenExchangeResource.

4. Si la propriété existe, le client envoie un TokenExchangeInvokeRequest au bot. Le client doit disposer d'un jeton échangeable pour l'utilisateur, qui doit être un jeton Microsoft Entra ID et dont l'audience doit être la même que la propriété TokenExchangeResource.Uri. Le client envoie une activité d’appel au bot avec le corps présenté ci-dessous.

   {
       "type": "Invoke",
       "name": "signin/tokenExchange",
       "value": {
           "id": "<any unique ID>",
           "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
           "token": "<exchangeable token>"
       }
   }
   

5. Le bot traite la demande TokenExchangeInvokeRequest et retourne une réponse TokenExchangeInvokeResponse au client. Le client doit attendre jusqu'à ce qu'il reçoive la réponse TokenExchangeInvokeResponse.

   {
       "status": "<response code>",
       "body": {
           "id":"<unique ID>",
           "connectionName": "<connection Name on the skill bot (from the OAuth Card)>",
           "failureDetail": "<failure reason if status code isn't 200, null otherwise>"
       }
   }
   

6. Si la réponse TokenExchangeInvokeResponse présente un status de 200, le client n'affiche pas la carte OAuth. Consultez le schéma du flux normal. Pour tout autre status ou si la réponse TokenExchangeInvokeResponse n'est pas reçue, le client montre la carte OAuth à l'utilisateur. Consultez le schéma du flux de secours. Cette fonction garantit que le flux SSO revient au flux OAuthCard normal en cas d'erreurs ou de dépendances non satisfaites, comme le consentement de l'utilisateur.

Étapes suivantes