シングル サインオン
適用対象: SDK v4
シングル サインオン (SSO) を使用すると、仮想アシスタント、WebChat などのクライアントが、ユーザーに代わってボットやスキルと通信できるようになります。 現在、Azure AD v2 ID プロバイダーのみがサポートされています。
SSO は、次のシナリオに適用されます。
- 仮想アシスタントと 1 つ以上のスキル ボット。 ユーザーは仮想アシスタントに 1 回サインインできます。 その後、アシスタントはユーザーに代わって複数のスキルを呼び出します。 仮想アシスタントも参照してください。
- Web チャットが Web サイトに埋め込まれています。 ユーザーが Web サイトにサインインします。 その後、Web サイトは、ユーザーに代わってボットまたはスキルを呼び出します。
SSO には、次の利点があります。
- 仮想アシスタントまたは Web サイトに既にサインインしている場合、ユーザーは再度ログインする必要はありません。
- 仮想アシスタントまたは Web サイトには、ユーザーのアクセス許可に関する知識がありません。
メモ
SSO は Bot Framework SDK v4.8 の新機能です。
SSO コンポーネントの相互作用
次のタイム シーケンス図は、SSO のさまざまなコンポーネント間の相互作用を示しています。
次の図は、仮想アシスタント クライアントを使用する場合の通常のフローを示しています。

WebChat クライアントを使用する場合の通常のフローとフォールバック フローを次に示します。

失敗した場合、SSO は、OAuth カードを表示する既存の動作に戻ります。 このエラーは、ユーザーの同意が必要な場合や、トークン交換が失敗した場合などに発生する可能性があります。
フローを分析しましょう。
クライアントは、OAuth シナリオをトリガーするボットとの会話を開始します。
ボットは OAuth カードをクライアントに返送します。
クライアントは、ユーザーに表示する前に OAuth カードをインターセプトし、プロパティが含まれている
TokenExchangeResourceかどうかを確認します。プロパティが exisists の場合、クライアントはボットに a
TokenExchangeInvokeRequestを送信します。 クライアントには、ユーザーの交換可能なトークンが必要です。これは、Azure AD v2 トークンでなければならず、対象ユーザーはプロパティと同じであるTokenExchangeResource.Uri必要があります。 クライアントは、次に示す本文を使用して、Invoke アクティビティをボットに送信します。{ "type": "Invoke", "name": "signin/tokenExchange", "value": { "id": "<any unique ID>", "connectionName": "<connection Name on the skill bot (from the OAuth Card)>", "token": "<exchangeable token>" } }ボットによって処理
TokenExchangeInvokeRequestされ、クライアントに戻りますTokenExchangeInvokeResponse。 クライアントは、.. を受信するまで待機する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>" } }が
TokenExchangeInvokeResponse含status200まれている場合、クライアントは OAuth カードを表示しません。 通常の フロー 図を参照してください。 その他statusの場合、または受信されていない場合TokenExchangeInvokeResponse、クライアントは OAuth カードをユーザーに表示します。 フォールバック フロー図を参照してください。 これにより、ユーザーの同意などのエラーや満たされていない依存関係が発生した場合に、SSO フローが通常の OAuthCard フローに確実に戻ります。