Ajouter l’authentification tierce aux actions universelles des cartes adaptatives
Les actions universelles de cartes adaptatives utilisent le bot comme back-end commun pour gérer les actions et introduisent un nouveau type Action.Execute
d’action , qui fonctionne dans les applications, telles que Teams et Outlook.
Remarque
La prise en charge du schéma d’actions universelles des cartes adaptatives version 1.4 n’est disponible que pour les cartes envoyées par le bot.
Vous pouvez activer les scénarios suivants avec Action.Execute
sur votre action universelle cartes adaptatives :
- Actions universelles
- Affichages spécifiques à l’utilisateur
- Flux de travail séquentiels
- Affichage à jour
Pour en savoir plus sur les actions universelles de cartes adaptatives, consultez Actions universelles de cartes adaptatives.
Si vous souhaitez ajouter des vues spécifiques à l’utilisateur dans les cas où une carte adaptative avec action universelle est partagée, dans le contexte d’une conversation de groupe ou d’un canal, l’utilisateur peut avoir besoin d’être authentifié.
Auparavant, les utilisateurs qui discutaient en face à face avec le bot devaient attendre que vous leur envoyiez une authentification distincte carte pour s’authentifier. Pour communiquer avec le bot, l’utilisateur doit passer de la conversation de groupe ou du canal qui perturberait le flux.
Flux d’authentification dans le protocole Action.Execute
Le flux d’authentification pour OAuth, dans le Action.Execute
protocole, active l’authentification dans le contexte de la conversation de groupe ou de la conversation de canal où la carte adaptative est partagée.
Les bots peuvent répondre avec une demande de connexion en réponse à pour Action.Execute
:
- Cartes adaptatives envoyées par le bot dans une conversation en face à face, une conversation de groupe ou un canal.
- Cartes adaptatives envoyées par l’utilisateur de l’application par le biais d’une application d’extension de message (soutenue par un bot) dans une conversation en face à face, une conversation de groupe ou un canal.
- Cartes adaptatives présentes dans la zone de composition ou d’aperçu pendant que l’utilisateur compose le message. Dans la zone de composition, l’actualisation de la carte adaptative fonctionne et le bot peut vouloir utiliser un jeton pour fournir une vue spécifique à l’utilisateur à l’utilisateur avant d’envoyer le carte à la conversation.
Bien démarrer avec OAuth ou le flux d’authentification nominale
Les étapes d’authentification OAuth ou nominale pour les cartes adaptatives avec des actions universelles sont similaires au bot dans Teams.
Veillez à ajouter l’authentification à votre bot Teams. Pour en savoir plus sur la création d’un bot avec authentification, sur le déploiement du bot sur Azure et son association à un fournisseur d’identité, et sur l’intégration du bot dans Microsoft Teams, consultez Ajouter l’authentification à votre bot Teams.
Pour une expérience d’authentification OAuth ou nominale dans laquelle un bouton ou un lien de connexion est présenté à l’utilisateur, voici le flux d’authentification OAuth ou nominal :
Le client Teams envoie une carte adaptative ou
actionInvokeActivity
une demande au bot.Le bot utilise le protocole token Service pour case activée s’il existe déjà un jeton mis en cache pour l’utilisateur spécifié dans le
activity.from.id
champ. Le canal est spécifié dans leactivity.channelId
champ du bot et de la connexion configurés.S’il existe un jeton mis en cache, le bot peut utiliser ce jeton. S’il n’y a pas de jeton, le bot crée une OAuthCard et la place dans la réponse avec les valeurs suivantes :
{ 'statusCode': 401, 'type': 'application/vnd.microsoft.activity.loginRequest', 'value': { 'text': 'Please sign-in', 'connectionName': '<configured-connection-name>', 'buttons': [ { 'title': 'Sign-In', 'text': 'Sign-In', 'type': 'signin', 'value': '<sign-in-URL>' } ] } }
- Les expéditeurs doivent inclure une valeur qui respecte le format OAuthCard.
- Les expéditeurs doivent inclure un
connectionName
. Les récepteurs peuvent ignorer les demandes de connexion avec un vide ou manquantconnectionName
. - Les expéditeurs doivent inclure un
button
qui a un tableau de boutons non vide.
Lors de la réception de cette réponse, le client Teams affiche un bouton De connexion dans le pied de page carte où l’utilisateur peut se connecter.
Lorsque l’utilisateur sélectionne le bouton Se connecter , la page de connexion du fournisseur d’identité s’ouvre dans une fenêtre de navigateur. Une fois que l’utilisateur s’est connecté, la page Service de jetons s’affiche avec une valeur de code d’autorisation.
Le client Teams crée et envoie l’activité d’appel
adaptiveCard/action
avecname
. La valeur inclut lestate
champ contenant le code d’autorisation :{ 'type': 'invoke', 'name': 'adaptiveCard/action' 'value': { 'action': { 'id': 'abc123', 'type': 'Action.Execute', 'verb': 'saveCommand', 'data': { 'firstName': 'Jeff', 'lastName': 'Derstadt' } }, 'state': '123456' }, ... }
Les expéditeurs doivent inclure un
state
champ.Le canal remet cet appel au bot, qui utilise le code d’authentification pour récupérer le jeton à partir du service d’émission de jetons. Le service token remet le jeton d’accès de l’utilisateur au bot.
Les récepteurs peuvent ignorer l’appel ou la
adaptiveCard/action
réponse avec une erreur s’il y a un champ manquant ou videstate
.Si la valeur du
state
champ est incorrecte, le bot retourne une erreur au client Teams comme suit :{ 'statusCode': 401, 'type': 'application/vnd.microsoft.error.invalidAuthCode', }
Le client Teams peut à nouveau demander à l’utilisateur le code d’autorisation correct ou peut renvoyer une
Action.Execute
demande.Si le code d’autorisation dans le
state
champ est correct, le bot utilise le jeton d’accès pour le compte de l’utilisateur pour effectuer ses actions.Le bot répond avec un carte ou un message au client Teams sans erreur.