次の方法で共有

アダプティブ カードユニバーサル アクションにサード パーティ認証を追加する

  • [アーティクル]

アダプティブ カードユニバーサル アクションは、アクションを処理するための共通バックエンドとしてボットを使用し、Teams や Outlook などのアプリ間で機能する新しいアクションの種類 Action.Executeを導入します。

注:

アダプティブ カードユニバーサル アクション スキーマ バージョン v1.4 のサポートは、ボットによって送信されたカードでのみ使用できます。

アダプティブ カードユニバーサル アクションで Action.Execute で次のシナリオを有効にすることができます。

アダプティブ カードユニバーサル アクションの詳細については、「 アダプティブ カードユニバーサル アクション」を参照してください。

ユニバーサル アクションを含むアダプティブ カードが共有されているインスタンスでユーザー固有のビューを追加する場合は、グループ チャットまたはチャネルのコンテキストで、ユーザーを認証する必要がある場合があります。

以前は、ボットと 1 対 1 でチャットしていたユーザーは、認証するために別の認証カードを送信している間に待機する必要がありました。 ボットと通信するには、ユーザーは、フローを妨げるグループ チャットまたはチャネルから切り替える必要があります。

Action.Execute プロトコルの認証フロー

OAuth の認証フローは、 Action.Execute プロトコル内で、アダプティブ カードが共有されているグループ チャットまたはチャネル会話のコンテキスト内で認証を有効にします。

ボットは、次の Action.Execute に応答してサインイン要求で応答できます。

  • ボットが 1 対 1 のチャット、グループ チャット、またはチャネルで送信するアダプティブ カード。
  • 1 対 1 のチャット、グループ チャット、またはチャネルでメッセージ拡張機能アプリ (ボットによってサポート) を介してアプリ ユーザーによって送信されるアダプティブ カード。
  • ユーザーがメッセージを作成しているときに、作成またはプレビュー領域に存在するアダプティブ カード。 作成領域でアダプティブ カードの更新が機能し、ボットがトークンを使用して、カードをチャットに送信する前に、アプリ ユーザーにユーザー固有のビューを提供したい場合があります。

OAuth または公称サインオン フローの概要

ユニバーサル アクションを使用したアダプティブ カードの OAuth または名目認証の手順は、Teams のボットに似ています。

Teams ボットに認証を追加したことを確認します。 認証が有効なボットを作成する方法、ボットを Azure にデプロイして ID プロバイダーに関連付ける方法、およびボットをMicrosoft Teams内に統合する方法の詳細については、「 Teams ボットに認証を追加する」を参照してください。

ユーザーにサインイン ボタンまたはリンクが表示される OAuth または公称サインオン エクスペリエンスの場合、OAuth または公称サインオン フローを次に示します。

ユニバーサル アクションを使用したアダプティブ カードの認証フローを示すスクリーンショット。

  1. Teams クライアントは、アダプティブ カードまたは actionInvokeActivity 要求をボットに送信します。

  2. ボットは Token Service プロトコルを使用して、activity.from.id フィールドに指定されたユーザーのキャッシュされたトークンが既にある場合にチェックします。 チャネルは、構成されているボットと接続の activity.channelId フィールドで指定されます。

  3. キャッシュされたトークンがある場合、ボットはこのトークンを使用できます。 トークンがない場合、ボットは OAuthCard を作成し、次の値で応答に配置します。

    {
  '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>'
        }
     ]
  }
}
    • 送信者には、OAuthCard 形式に準拠する値を含める必要があります。
    • 送信者には、 connectionNameを含める必要があります。 受信者は、空または不足している connectionNameを持つサインイン要求を無視する可能性があります。
    • 送信者には、空でないボタン配列を持つ button を含める必要があります。

  4. この応答を受け取ると、Teams クライアントはカード フッターにサインイン ボタンを表示し、ユーザーはサインインできます。

    アダプティブ カードの [Sign-In] ボタンを示すスクリーンショット。

  5. ユーザーが [サインイン ] ボタンを選択すると、ID プロバイダーのサインイン ページがブラウザー ウィンドウで開きます。 ユーザーがサインインすると、[トークン サービス] ページに承認コード値が表示されます。

  6. Teams クライアントは、nameを使用してadaptiveCard/action呼び出しアクティビティを作成して送信します。 値には、承認コードを含む state フィールドが含まれます。

    {
   'type': 'invoke',
   'name': 'adaptiveCard/action'
   'value': {
      'action': {
         'id': 'abc123',
         'type': 'Action.Execute',
         'verb': 'saveCommand',
         'data': {
            'firstName': 'Jeff',
            'lastName': 'Derstadt'
         }
      },
   'state': '123456'
   },
   ...
}

    送信者には、 state フィールドを含める必要があります。

  7. チャネルは、認証コードを使用してトークン サービスからトークンを取得するボットにこの呼び出しを配信します。 Token Service は、ユーザーのアクセス トークンをボットに配信します。

    受信者は、 adaptiveCard/action 呼び出しを無視するか、 state フィールドが空の場合にエラーで応答する可能性があります。

    [ state ] フィールドの値が正しくない場合、ボットは次のように Teams クライアントにエラーを返します。

      {
   'statusCode': 401,
   'type': 'application/vnd.microsoft.error.invalidAuthCode',
  }

    Teams クライアントは、ユーザーに正しい承認コードの入力を再度求めたり、 Action.Execute 要求をもう一度送信したりできます。

  8. [ state ] フィールドの承認コードが正しい場合、ボットはユーザーの代わりにアクセス トークンを使用してそのアクションを実行します。

  9. ボットは、エラーなしで Teams クライアントにカードまたはメッセージで応答します。

関連項目