Résolution des problèmes d'authentification SSO dans Teams

Pour obtenir plus d’informations, consultez Utilisation de Postman avec l’API Microsoft Graph.

Pour plus d'informations, voir Explorateur de graphiques.

Votre code doit indiquer au client (par exemple, dans le corps d’une réponse 403 Interdit) comment gérer l’erreur :

• Si l'application de l'onglet nécessite des scopes Microsoft Graph pour lesquels seul un administrateur peut donner son accord, votre code devrait générer une erreur.
• Si les seules étendues requises peuvent être envoyées par l’utilisateur, votre code doit basculer vers un autre système d’authentification des utilisateurs.

Pour gérer cette erreur, votre code côté serveur doit envoyer une réponse 403 Interdit au client. Il doit consigner l'erreur dans la console ou l'enregistrer dans un journal.

1. Le domaine personnalisé n’est pas ajouté à l’ID Microsoft Entra. Pour ajouter un domaine personnalisé à l’ID Microsoft Entra et l’inscrire, suivez la procédure Ajouter un nom de domaine personnalisé à l’ID Microsoft Entra . Ensuite, suivez à nouveau les étapes pour configurer l’étendue du jeton d’accès .
2. Vous n’êtes pas connecté avec les informations d’identification d’administrateur dans la location Microsoft 365. Connectez-vous à Microsoft 365 en tant qu'administrateur.

Pour plus d'informations, voir Fournir des revendications facultatives à votre application et des jetons d'accès.

Pour plus d'informations sur l' URI de l'application, voir Pour exposer une API .

L’image suivante montre un exemple des détails de l’application configurés dans l’ID Microsoft Entra.

Vérifiez que les valeurs suivantes correspondent entre l’ID Microsoft Entra, le code côté client et le manifeste de l’application :

• ID d’application : l’ID d’application que vous avez généré dans l’ID Microsoft Entra doit être identique dans le code et dans le fichier manifeste de l’application. Vérifiez si l’ID d’application dans le schéma du manifeste d’application correspond à l’ID d’application (client) dans l’ID Microsoft Entra.

• Secret de l’application : le secret d’application configuré dans le back-end de votre application doit correspondre aux informations d’identification du client dans l’ID Microsoft Entra. Vous devez également vérifier si le secret du client a expiré.

• URI d’ID d’application : l’URI de l’ID d’application dans le code et dans le fichier manifeste de l’application doit correspondre à l’URI d’ID d’application dans l’ID Microsoft Entra.

• Autorisations de l'application : Vérifiez si les autorisations que vous avez définies dans le champ d'application correspondent aux besoins de votre application. Si c’est le cas, vérifiez si elles ont été accordées à l’utilisateur dans le jeton d’accès.

• Consentement de l'administrateur : si un champ d'application nécessite le consentement de l'administrateur, vérifiez si le consentement a été accordé à l'utilisateur pour ce champ d'application particulier.

En outre, inspectez le jeton d'accès qui a été envoyé à l'application de l'onglet pour vérifier si les valeurs suivantes sont correctes :

• Audience (aud) : vérifiez si l’ID d’application dans le jeton est correct, comme indiqué dans l’ID Microsoft Entra.
• Tenant Id(tid) : Vérifier si le locataire mentionné dans le jeton est correct.
• Identité de l’utilisateur (preferred_username) : vérifiez si l’identité de l’utilisateur correspond au nom d’utilisateur dans la demande de jeton d’accès, pour l’étendue à laquelle l’utilisateur actuel souhaite accéder.
• Étendues (scp) : vérifiez si l’étendue pour laquelle le jeton d’accès est demandé est correcte et telle que définie dans l’ID Microsoft Entra.
• Microsoft Entra version 1.0 ou 2.0 (ver) : vérifiez si la version de Microsoft Entra est correcte.

Vous pouvez utiliser JWT pour inspecter le jeton.

{​​ 
    "status": "<response code>", 
    "body": 
    {​​ 
        "id":"<unique Id>", 
        "connectionName": "<connection Name on the bot (from the OAuth card)>", 
        "failureDetail": "<failure reason if status code is not 200, null otherwise>" 
    }​​ 
}​​

Pour comprendre le comportement du bot lorsque l’échange de jetons ne parvient pas à déclencher une invite de consentement, consultez les étapes suivantes :

1. Le client démarre une conversation avec le bot déclenchant un scénario OAuth.

2. Le bot renvoie une carte OAuth au client.

3. Le client intercepte la carte OAuth avant de l’afficher à l’utilisateur de l’application. Il vérifie s’il contient une TokenExchangeResource propriété.

4. Si la propriété existe, le client envoie un TokenExchangeInvokeRequest message au bot. Le client doit avoir un jeton échangeable pour l’utilisateur. Ce jeton doit être un jeton Azure AD v2 dont l’audience doit être identique à TokenExchangeResource.Uri la propriété.

5. Le client envoie une activité d’appel au bot avec le code suivant :

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

6. Le bot traite et TokenExchangeInvokeRequest retourne un TokenExchangeInvokeResponse retour au client. Le client doit attendre jusqu’à ce qu’il reçoive le 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 is not 200, null otherwise>"
       }
   }
   

7. Si la TokenExchangeInvokeResponse valeur est status de 200, le client n’affiche pas la carte OAuth. Afficher l’image de flux normal Pour tout autre ou status si le TokenExchangeInvokeResponse n’est pas reçu, le client affiche la carte OAuth à l’utilisateur. Afficher l’image de flux de secours En cas d’erreurs ou de dépendances non satisfaites telles que le consentement de l’utilisateur, cette activité garantit que le flux d’authentification unique revient au flux OAuthCard normal.

   Remarque

   Dans le client web Teams, l’invite de mot de passe n’apparaît pas, car il existe une session Microsoft Entra active dans le navigateur, qui est utilisée pour l’authentification et pour acquérir un jeton. Dans le client de bureau Teams, l’invite de mot de passe s’affiche, car le client de bureau n’a pas de session Microsoft Entra à partager et est invité à se connecter.