Teams での SSO 認証のトラブルシューティング

詳細については、「Microsoft Graph API で Postman を使用する」をご覧ください。

詳細については、「Graph エクスプローラー」を参照してください。

コードは、クライアントに (たとえば、403 Forbidden 応答の本文で) エラーを処理する方法を伝える必要があります。

• タブ アプリに管理者のみが同意できる Microsoft Graph スコープが必要な場合は、コードでエラーを生成する必要があります。
• 唯一必要なスコープに対して同意できるのがユーザーである場合は、コードはユーザー認証の代替システムにフォールバックする必要があります。

このエラーを処理するには、サーバー側のコードから 403 Forbidden 応答がクライアントに送信されます。 そのエラーをコンソールに記録するか、ログに記録する必要があります。

1. カスタム ドメインは Microsoft Entra ID には追加されません。 カスタム ドメインを Microsoft Entra ID に追加して登録するには、 Microsoft Entra ID にカスタム ドメイン名を追加する手順に 従います。 次に、「アクセス トークンのスコープをもう一度 構成する」の 手順に従います。
2. Microsoft 365 テナントで管理者の資格情報を使用してサインインしていません。 管理者として Microsoft 365 にサインインします。

詳細については、「アプリにオプションの要求を提供する」と「アクセス トークン」を参照してください。

アプリケーション ID URI の詳細については、「API を公開するには」を参照してください。

次の図は、Microsoft Entra ID で構成されたアプリの詳細の例を示しています。

次の値が Microsoft Entra ID、クライアント側コード、アプリ マニフェストの間で一致することを確認します。

• アプリ ID: Microsoft Entra ID で生成したアプリ ID は、コードとアプリ マニフェスト ファイルで同じである必要があります。 アプリ マニフェスト スキーマのアプリ ID が Microsoft Entra ID のアプリケーション (クライアント) ID と 一致するかどうかを確認します。

• アプリ シークレット: アプリのバックエンドで構成されているアプリ シークレットは、Microsoft Entra ID の クライアント資格情報 と一致する必要があります。 クライアント シークレットの有効期限が切れているかどうかも確認する必要があります。

• アプリケーション ID URI: コード内およびアプリ マニフェスト ファイル内のアプリ ID URI は、Microsoft Entra ID のアプリケーション ID URI と一致する必要があります。

• アプリのアクセス許可: スコープで定義したアクセス許可がアプリの要件に従っているかどうかを確認します。 その場合は、アクセス トークンでユーザーに付与されているかどうかを確認します。

• 管理者の同意: スコープに管理者の同意が必要な場合は、特定のスコープに対してユーザーに同意が付与されているかどうかを確認します。

さらに、タブ アプリに送信されたアクセス トークンを調べて、次の値が正しいかどうかを確認します:

• 対象ユーザー (aud): トークン内のアプリ ID が Microsoft Entra ID で指定されているとおりに正しいかどうかを確認します。
• テナント ID (tid): トークンに記載されているテナントが正しいかどうかを確認します。
• ユーザー ID (preferred_username): 現在のユーザーがアクセスするスコープについて、アクセス トークンの要求でユーザー ID がユーザー名と一致するかどうかを確認します。
• スコープ (scp): アクセス トークンが要求されるスコープが正しく、Microsoft Entra ID で定義されているかどうかを確認します。
• Microsoft Entra バージョン 1.0 または 2.0 (ver): Microsoft Entra のバージョンが正しいかどうかを確認します。

JWT を使用してトークンを検査できます。

{​​ 
    "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>" 
    }​​ 
}​​

トークン交換が同意プロンプトのトリガーに失敗した場合のボットの動作を理解するには、次の手順を参照してください。

1. クライアントは、OAuth シナリオをトリガーするボットとの会話を開始します。

2. ボットは OAuth カードをクライアントに返送します。

3. クライアントは、OAuth カードをアプリ ユーザーに表示する前にインターセプトします。 TokenExchangeResource プロパティが含まれているかどうかを確認します。

4. そのプロパティが存在する場合、クライアントはボットに TokenExchangeInvokeRequest を 1 つ送信します。 クライアントには、ユーザーの交換可能なトークンが必要です。 このトークンは、対象ユーザーが TokenExchangeResource.Uri プロパティと同じである必要がある Azure AD v2 トークンである必要があります。

5. クライアントは、次のコードを使用してボットに呼び出しアクティビティを送信します:

   {
       "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. ボットは TokenExchangeInvokeRequest を処理し、TokenExchangeInvokeResponse を 1 つクライアントに返します。 クライアントは、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. TokenExchangeInvokeResponse に 200 の status がある場合、クライアントは OAuth カードを表示しません。 通常のフロー イメージを参照してください。 その他の status の場合、または TokenExchangeInvokeResponse が受信されていない場合、クライアントは OAuth カードをユーザーに表示します。 フォールバック フロー イメージを参照してください。 ユーザーの同意など、エラーや依存関係が満たされていない場合、このアクティビティにより、確実に SSO フローが通常の OAuthCard フローに戻ります。

   注:

   Teams Web クライアントでは、認証とトークンの取得に使用されるアクティブな Microsoft Entra セッションがブラウザーに存在するため、パスワード プロンプトは表示されません。 Teams デスクトップ クライアントでは、デスクトップ クライアントに共有する Microsoft Entra セッションがないため、パスワード プロンプトが表示され、ログインするように求められます。