Entra ID × Identity Center × Cognitoで社内AIエージェントアプリにSSOでログインする

はじめに

こんにちは、ふくちと申します。

先日、社内用MCPサーバーをAgentCore Gatewayで構築した際の認証認可周りの設定についてのブログを書きました。現代人に読ませる気ねーだろってレベルの長文ブログになってしまいましたが…

ここの中で、Entra ID・Identity Center(以降IICと記載)・Cognito周りの連携をすごくさらっと流してしまったので、本ブログで追加解説しようと思います。

あとAmplify × AgentCore Runtimeの構成だけだと中々組織展開できるAIエージェントアプリにはならないので、ログイン周りのところを整理したかったというところがあります。

ざっくり結論から

この構成とフローを理解してもらおうというのが本記事のゴールです。

↓

• 会社のEntra IDをIICの外部IdPとして使う
• IICにカスタムSAMLアプリケーションを登録する
• CognitoユーザープールをSAMLのSPとして設定する
• WebアプリはCognitoのマネージドログインとOAuth認証コード付与を使う
• WebアプリからAgentCore RuntimeへCognitoのJWTを送る

おまけを除いてざっくりログインフローを整理すると、こんな感じです。
※この最初の図では仕組みを追いやすくするために専門用語をできるだけ省きました。詳しくは後ほど。

この構成をものすごく雑にハンターハンターで例えると、

• あなた(プロのハンター)はとある国もしくは施設に入りたい
• Entra IDは、あなたが正規のハンターライセンスを持つ本人かを確認する本人確認窓口
• IICは、あなたをどの施設や国へ通してよいかを管理する協会の総合受付
• Cognitoは、総合受付から渡された署名付きの入場証を検証し、入国/入館で使える一時パスをあなたに発行する国/施設側の受付

という形になります。ほんまか…？

ここで1つ大事な点があるとすれば、Entra IDからWebアプリへ直接トークンが届くわけではないことです。つまりハンターライセンスを持っているからといって何でもできるわけではないということ。

Entra IDのSAMLアサーションはまずIICへ渡り、IICが別のSAMLアサーションをCognitoへ渡します。
Cognitoはその結果を受けて、Webアプリが扱いやすいOAuth 2.0 / OIDCのトークンを発行します。

つまり、アプリが最終的に信頼する発行者はEntra IDではなくCognitoです。
バックエンドも、通常はEntra IDのSAML XMLを直接解析しません。Cognitoが発行したJWTを検証します。

役割を整理する

まず、今回出てくる主要な3サービスの役割や関係性をまとめます。

Entra ID

Microsoft Entra IDはざっくり言うと会社のユーザーを認証するサービスです。
ユーザー名、パスワード、多要素認証、条件付きアクセスなど、会社のサインインポリシーを適用可能です。

この構成では、Entra IDは上流のIdentity Provider(IdP)として動きます。

IdPとは、早い話が認証基盤です。
本人確認してOKなら"認証済み"のステータスを発行するのが役割です。

Cognitoユーザープール

Cognitoユーザープールは、アプリケーションのユーザー基盤です。
ユーザー情報を管理し、ログイン画面やOAuth 2.0 / OIDCの認可サーバー機能を提供します。

ここでは、Cognitoが2つの処理を行います。

1. SAMLのSPとしてIICから認証結果を受け取る
2. OAuth 2.0 / OIDCの認可サーバーとしてWebアプリへトークンを発行する

CognitoがSAMLをOAuth 2.0 / OIDCへ変換するため、Webアプリやバックエンドは会社ごとのEntra ID実装を意識せず、CognitoのJWTを検証すればOKです。

詳しいフローはこの後のIICの章で解説しています。

また、今回使うのはCognitoユーザープールです。Cognitoアイデンティティプールとは別のサービスです。

ユーザープールはユーザー認証とJWT発行を担当し、アイデンティティプールは認証済みユーザーへ一時的なAWS認証情報を渡す仕組みです。
Webアプリのログインだけが目的なら、AWS認証情報をユーザーへ渡す必要はありません。

Identity Center

AWS IAM Identity Centerは、AWSアカウントやアプリケーションに対する社内ユーザーの入口を1つにまとめるサービスです。
ここではAWSアカウントへのアクセス管理ではなく、自作アプリケーションへのアクセス管理目的で用います。

この構成では、IICが2つの役割を持ちます。

• Entra IDから見ると、IICはログイン結果を受け取るService Provider(SP)
• Cognitoから見ると、IICはSAMLアサーションを発行するIdP

SPとは、サービス提供側です。
IdPの認証結果を受け取り、検証してサービスを提供する側のことを指します。

このIdPとSPはサービス全体に固定された肩書きではありません。
どの相手と連携するかでIICの役割が変わるということです。

ここまでを踏まえて今回の構成を整理すると、次のようになります。

処理	サービス	確認すること
ユーザー認証	Entra ID	会社のユーザーが本人か
アプリへの入口の認可	IIC	対象ユーザーやグループにアプリ割り当てがあるか
アプリ向けセッション発行	Cognito	SAMLアサーションを検証し、トークンを発行できるか
APIリクエストの認証	API Gateway / AgentCore Runtime	JWTが正しい発行者から発行され、改ざんされていないか

つまり、会社SSOに成功して(=認証が通って)画面が表示されたとしても、すべてのAPIやツールが使えるとは限らない(=認可次第)ということです。

図にすると、冒頭の図と同じ感じになります。次はこのSAML連携についてもう少し整理していきます。

SSOとフェデレーションとSAML

SAMLの解説にあたっては、SSO(Single Sign-On)を理解する必要があります。
SSOは、一度ログインしたユーザーが別のサービスへ再度パスワードを入力せずに入れる体験を指します。

今回のケースで言えば、会社のEntra IDにログインしていれば、Webアプリを自由に使うことができるようになっています。

SSOは利用者目線での体験の名前であり、特定の通信規格などの名前ではありません。

SSOに使われる仕組みとして、フェデレーションというのがあります。

フェデレーションは、あるシステムの認証結果を別のシステムが信頼する仕組みです。
今回の構成で言えば、Entra IDで本人確認した結果をIICが信頼し、IICで確認した結果をCognitoが信頼します。

そしてそのフェデレーションにおいて使われる規格をSAMLといいます。

SAMLはフェデレーションに使う標準規格の一つです。SAMLでは、認証結果をSAMLアサーションという署名付きXMLで渡します。XMLの中にはユーザーを識別する値や、メールアドレスなどの属性が含まれます。

ここは以前の記事でも触れたところなので、より詳しく知りたい方は下記をご参照ください。

SAMLRequestとSAMLResponse

先ほどのEntra ID・IIC・Cognitoのフロー図では、SAMLによる連携が2つ登場しました。

1つ目は、CognitoとIICの連携です。
Cognitoが認証要求をIICへ送り、IICが認証結果をCognitoへ返します。

2つ目は、IICとEntra IDの連携です。
IICがEntra IDへ認証要求を送り、Entra IDが認証結果をIICへ返します。

これらがSAMLRequestとSAMLResponseです。

SAMLRequestは、SPがIdPへ「このユーザーを認証してほしい」と依頼するメッセージです。
SAMLResponseは、IdPがSPへ返す応答です。この中には、認証に成功したことを示すSAMLアサーションというものが含まれます。

実際の通信ではこれらのメッセージをブラウザが中継します。そのため、ログイン時には複数のURLへ自動的に移動します。

SAMLRequestやSAMLResponseをブラウザ経由で送る方法をBindingと呼びます。
代表的なものにHTTP Redirect Binding・HTTP POST Binding・HTTP Artifact Bindingがあるそうです。

ここではRedirectとPOSTのみを取り上げます。

Bindingとは

Bindingは、SAMLメッセージをHTTPでどう運ぶかを決めるルールです。あくまでメッセージのやり取り方式なだけで、前述のSAMLRequestやSAMLResponseそのものとは別の概念です。

RedirectとPOSTにはそれぞれ以下の違いがあります。

• HTTP Redirect Binding：URLの後ろにメッセージを付けてブラウザを移動させる方法
• HTTP POST Binding：ブラウザに一時的なHTMLフォームを表示し、そのフォームを自動送信する方法

HTTP Redirect Binding

Redirectは文字通り、URLに情報を付けておくことでブラウザにそのURLへ直接移動させるという方式です。

例えばCognitoがIICへ認証を依頼するとき、Cognitoはブラウザへリダイレクトを返します。
そのリダイレクト先URLに、SAMLRequestをパラメータとして含めます。

HTTP/1.1 302 Found
Location: https://sso.example.com/saml/login?SAMLRequest=<エンコードされた認証要求>

ブラウザはこのLocationのURLへ移動します。すると、IICはURLのSAMLRequestを読み取り、「このユーザーを認証してほしい」という依頼を受け取れます。

画面で見ると、次のような動きです。

HTTP POST Binding

POSTは、ブラウザにフォームを渡しそのフォームを自動的に送信させる、という方式です。

例えば、IICがCognitoへSAMLResponseを返すとき、ブラウザに次のようなHTMLを返すイメージです。

<form method="post" action="https://app.example.com/saml2/idpresponse">
  <input type="hidden" name="SAMLResponse" value="<エンコードされた認証結果>">
</form>
<script>
  document.forms[0].submit();
</script>

これを受け取ったブラウザがJavaScriptによってフォームの自動送信まで行うので、ユーザーはフォームを操作しません。
送信先のCognitoはHTTP POSTの本文からSAMLResponseを取り出して検証します。

画面で見ると、次のような動きです。

このため、POST BindingではURLのクエリパラメータにSAMLResponseが見えないことがあります。
もし確認したい場合は、ブラウザの開発者ツールで送信先へのPOSTリクエストとフォームデータを見ると確認できるようです。

実際のログインフロー例

本構成におけるログインフローでは、次の流れです。ここでは、Cognitoの認可エンドポイントからログインを始めるSP起点のログインを例にします。

IICとEntra IDの間でも同じように、認証要求・認証結果のやり取りが発生します。

ただし、実際にどのBindingを使うかは、SPとIdPの製品や設定によって決まります。
CognitoのSAML連携では、SAMLResponseを受け取るACSエンドポイントがPOST Bindingを使う構成になっています。

SAML連携

ここからは具体的なSAML連携の話です。先程のEntra IDとIIC、IICとCognitoのそれぞれに分けて解説します。

Entra IDとIIC

こちらではEntra IDがIdP、IICがSPにあたります。

システム	役割	役割の意味
Entra ID	IdP	ユーザーを認証し、SAML Assertionを発行する
IIC	SP	Entra IDのSAML Assertionを受け取り、AWS側のセッションを開始する

全体的なフローとしては上記のとおりなのですが、Entra IDとIICの連携ではSAMLだけでなくSCIMも登場します。これはフローに書かれていない要素なので補足しておきます。

SCIMはSystem for Cross-domain Identity Managementの略で、自動的なIDプロビジョニング(ユーザーやグループを別のサービスへ作成、更新、削除する)を実現するための標準規格です。

SAMLとSCIMの役割は明確に異なります。

SAMLはログイン時の認証結果を渡す、つまり認証を担います。
ただし、SAMLではSPがIdPにどんなユーザー/グループが存在するかを確認する機能はありません。なのでIdP(今回はIIC)にはユーザー/グループを事前登録・設定してあげる必要があります。そこでSCIMを使います。

SCIMはSAMLの前段、すなわちログインしていないユーザーやグループの情報を事前にSPへ登録したり、更新があったら反映したりします。今回で言うとEntra IDからIICに登録する感じです。
複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するのが主な役割なんだそうです。

したがって、Entra IDとIICの間には、次の二つの流れがあります。

• ログイン時のSAML
• ユーザー・グループ同期時のSCIM

SCIMで同期されたグループが、IIC上のアプリ割り当てに使われます。

こちらの具体的な設定方法などは別資料をご参照ください。

IICとCognito

こちらではIICがIdP、CognitoがSPにあたります。

システム	役割	役割の意味
IIC	IdP	CognitoへSAML Assertionを発行する
Cognitoユーザープール	SP	SAML Assertionを受け取り、 ユーザーをCognitoへフェデレーションする

先程のEntraID・IICのフローの最後でWebアプリが開くところまで進んでいるのが前提で、その後WebアプリがCognitoのアプリケーションクライアントを使ってログイン処理を行います。

IICとCognitoの設定手順

この連携を設定するため、IICとCognitoの設定をそれぞれ行います。

1.Cognito作成

まずCognitoユーザープールとドメインを作成しておきます。

Cognitoコンソールで新しいユーザープールを作成します。
アプリケーションタイプはフロントエンドの構成次第ですが、例えばReact + Viteで作ったブラウザSPAをS3/CloudFrontから配信している場合、シングルページアプリケーション(SPA)を選びます。

画像の「オプションを設定」は、現在の構成では次の設定で問題ありません。

画面の項目	設定	理由
サインイン識別子	メールアドレス のみ	IICから返るメールアドレスをCognitoユーザーの識別に使うため。電話番号とユーザー名は選ばない
自己登録	オフ	ユーザーの作成と会社アカウントの本人確認はEntra IDとIICに任せ、一般ユーザーがCognitoへ直接登録できないようにするため
サインアップの必須属性	email	IICのSAML属性マッピングでメールアドレスをCognitoの email に渡すため(後述)

ここでSPAの選択すると、Cognitoユーザープールに作るブラウザ用のアプリケーションクライアントの設定がSPA用のものになります。後の手順でIICをCognitoのSAML IdPとして登録し、アプリケーションクライアントでSSOを有効化します。

作成できたら、ドメインを設定します。ユーザープールのドメイン画面でブランディングのバージョンをマネージドログインに設定します。ここに記載されているドメイン(URL)が、Cognitoログインページのリンクです。

ここまで来たら、下記の値を控えます。
1つ目はユーザープールID、下記の赤枠内です。これが後述するSAMLオーディエンスというやつになります。IIC側で必要になります。

2つ目は先ほど確認したCognitoドメインです。こちらも後述するACS URLに設定する際必要になります。

2.IICでカスタムSAMLアプリケーションを作る

続いて、IIC側での作業です。

IICコンソールにおいて、アプリケーション→アプリケーションを追加→セットアップしたいアプリケーションがある→SAML 2.0のカスタムアプリケーション、まで選択します。設定する値は次のとおりです。

↓

その後、下記を設定していきます。

設定項目	入れる値	何のためか
表示名	任意のアプリ名	ポータルのタイルに表示される名前
アプリケーション開始URL	アプリのURL	ポータルのタイルから開く先
アプリケーションACS URL	ACS URL	SAML Responseの届け先
アプリケーションSAMLオーディエンス	SP Entity ID	認証結果の宛名

アプリケーション開始URLは独自ドメインのアプリリンクだったり、CloudFrontやAmplifyが発行するURLだったりを設定します。

ここでACS URLとSAMLオーディエンスについてそれぞれ補足しておきます。

まずACSですが、これはAssertion Consumer Serviceの略です。SAML IdPが発行したSAML Responseを、SPが受け取るエンドポイントを指します。

今回の構成で言えば、IICが発行したSAML Responseを受け取るCognito側のエンドポイントを設定する形です。Cognito側のエンドポイントのフォーマットはこんな感じ。先ほど確認したCognitoドメインですね。

https://<cognito-domain>.auth.<region>.amazoncognito.com/saml2/idpresponse

このエンドポイントをIICのカスタムアプリケーションでACS URLとして登録する必要があります。

続いてSAMLオーディエンス。ただしこれを理解するためにはEntity IDについても簡単に理解する必要があります。

Entity IDとはIdPがアプリケーションを特定するための一意なIDです。Cognitoでは、ユーザープールごとに次の形式を使います。先ほどコピーしたユーザープールIDを末尾につけます。

urn:amazon:cognito:sp:<user-pool-id>

SAML Responseのオーディエンスは、この認証結果をどのSP向けに発行したかを表します。IICには、CognitoのSP Entity IDをオーディエンスとして設定します。

これらをアプリケーションメタデータの欄に入力しておきます。

より詳細に知りたい方は下記などが参考になると思います。

また、作成画面にはIICのSAMLメタデータファイルURLが表示されます。これが手順4でCognitoへ渡す値なので、控えておきましょう。

これはIICの署名証明書とSSOエンドポイントの情報が入った設定文書で、CognitoがIICを信頼するための根拠になります。

ここまでできたら、SAMLアプリを作成してOKです。

その後、作成したSAMLアプリのユーザーとグループを割り当てで、グループを割り当てます。この割り当てが、SSOの入口を使えるユーザーの範囲を決める最初の認可です。割り当てのないユーザーは、Cognitoに到達する前にIICで拒否されます。

IICの属性マッピング

そしてIIC最後の設定です。属性マッピングというのを行います。

属性マッピングとは、IdPが持つユーザー情報をSPが使う属性名へ変換する対応表です。
なのでEntra ID→IICの連携でもEntra ID側にこれが設定されているはずですが、ただそれはAWS側から確認できないので、ここでは省略します。

なので、ここではIIC→SAMLアプリ(ここではCognito)の属性マッピングを解説します。

改めてここでの属性マッピングとは、IICのユーザー属性とSAMLアプリ(Cognito)が要求する属性名を対応づける設定です。IICはここで指定された対応に従い、ログイン時のSAML Assertionへ属性名とユーザーごとの値を出力します。それがCognitoに渡るイメージ。

2.では下記の左側を設定し、後続の3.で右側を設定します。

少し説明が長くなりましたが、改めてこの流れをコンソールで構築していきます。

先ほど作成したSAMLアプリの属性マッピングを選択すると、アプリケーションが要求する属性名とIICのユーザー属性を入力できる画面に移行します。
これを設定することで、ログイン時のSAML AssertionではIICの属性値がアプリ属性名のクレームとして出力されます。

参考までにこんな感じの値を設定します。

アプリのユーザー属性	IICの属性	フォーマット	意味
Subject	${user:email}	emailAddress	SAMLのSubject/NameIDに入れる値。Cognitoがフェデレーションユーザーを識別する材料
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	${user:email}	unspecified	Assertion内のメール属性のキー。ここにIIC上のメールアドレスを入れる
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	${user:preferredUsername}	unspecified	Assertion内の名前属性のキー。ここにIIC上の表示名を入れる

簡単に設定値についても補足しておきます。
まずアプリ属性側でhttps://.../emailやhttps://.../nameというのがあります。これはSAML Assertion内の属性を識別するための固定の名前(URI形式のクレーム名)です。

また、IIC属性値で設定している${user:email}や${user:preferredUsername}は、ログインしたユーザーのディレクトリ属性を実行時に取り出し、そのユーザーの実際のメールアドレスや表示名に置き換えてくれます。変数みたいなもんですね。

ちなみにSubjectとIIC属性に同じ ${user:email} を指定しているのは重複ではありません。

Subjectは、Cognitoが誰のプロファイルとして扱うか、を決めるものです。つまりログイン機能に必要な情報としての設定ということです。

一方IICのメールアドレス属性は、そのプロファイルのemailに何を保存するか、を決めます。名前属性と合わせて、フロントエンドにログインユーザーとメールアドレスを表示するためのものです。すなわち、ログインさえできれば良いのであればこちらの設定は不要です。

3. Cognito SAMLプロバイダーの属性マッピング

先程のフロー図でいう右側を設定します。

CognitoのSAMLプロバイダーとは、SAML Assertionの属性名をユーザープール属性へ書き込む設定です。例えば、CognitoはAssertionを検証した後、メールクレームの値をユーザープールのemailに保存する、みたいな感じです。

ではこれを実際に設定していきます。

先ほど作成したCognitoユーザープールにおいて、ソーシャルプロバイダーと外部プロバイダー →アイデンティティプロバイダーを追加 → SAMLを選びます。

後続の設定は以下の感じです。記載していないものは空欄でOK。

設定項目	入れる値	理由など
プロバイダー名	任意	何でも良いです
IdPが開始したSAMLサインイン	SPが開始するSAMLアサーションが必要にチェック	アプリ→Cognito→IICの順にログインを開始する構成のため
メタデータドキュメントURL	手順3で控えたIICメタデータURL	IICの署名を検証するための情報源
サインアウトフロー	チェックしない	本構成ではアプリとCognitoまでのサインアウトを行うため。IIC/EntraまでのSingle Logoutは考慮しない

最後にCognito側での属性マッピングです。本構成では下記を設定します。

ユーザープール属性	SAML属性	理由など
email	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Assertionのメール値がユーザープールの必須属性 email に保存される
name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Assertionの名前値がユーザープールの表示名に保存される

4.アプリケーションクライアントを設定する

続いて、Cognitoユーザープールのアプリケーションクライアントを設定します。
これは最初にSPAで設定した通りブラウザで動くWebアプリ用なので、クライアントシークレットなしのパブリッククライアントとして作ります。

その後、マネージドログインページを編集のページを開き、下記4項目を設定します。

設定項目	入れる値	理由など
許可されているコールバックURL	アプリのURL	認証後にCognitoが認可コードを返し、アプリがログイン後の画面を表示するため
許可されているサインアウトURL	アプリのURL	Cognitoのログアウト処理後に、アプリのサインイン前画面へ戻るため
IDプロバイダー	手順3で設定したSAMLプロバイダー	このアプリクライアントでIIC経由のSAML認証を使えるようにするため
OAuth 2.0 許可タイプ	認証コード付与	SPAが直接アクセストークンを受け取らず、認可コードをCognitoのトークンエンドポイントでトークンへ交換する方式
OpenID Connect のスコープ	openid, email, profile	openidはIDトークン発行のため、emailやprofileは標準プロフィール属性をトークンやユーザー属性取得で利用するため

5.アプリへ設定値を渡す

ここまでにできた値を、Webアプリの認証SDKへ渡します。

例えばAmplify Authを使うのであれば、ユーザープールID、クライアントID、リージョン、Cognitoドメイン、コールバックURLを設定し、ログインボタンで signInWithRedirect({ provider: { custom: "<SAMLプロバイダー名>" } }) をコールします。

Cognitoの認可エンドポイントへブラウザをリダイレクトし、Cognitoへ設定したSAMLプロバイダーという外部IdPを使うよう伝えるようなイメージのコードです。

await signInWithRedirect({
  provider: { custom: "<SAMLプロバイダー名>" },
});

その際、実際のURLは概念的には次のようになります。

https://<cognito-domain>/oauth2/authorize
  ?response_type=code
  &client_id=<web-client-id>
  &redirect_uri=https%3A%2F%2F<app-origin>%2Fauth%2Fcallback
  &scope=openid%20email%20profile
  &identity_provider=<SAMLプロバイダー名>
  &state=<random-state>
  &nonce=<random-nonce>
  &code_challenge=<base64url-challenge>
  &code_challenge_method=S256

Cognitoのドメインを使うため、マネージドログインの基盤は使っています。しかしidentity_provider=<SAMLプロバイダー名>を指定しているため、ユーザーにパスワード入力画面やIdP選択画面を表示せず、SSOでのログイン体験を提供する形になります。

Entra IDにログインしていれば、何も入力しなくともログインができます。Entra IDにログインしていなければそのログインを求められて、そこのログインが完了したらアプリには自動でアクセスできます。

余談ですが、ログインボタンを押した後の遷移ステータスを図にすると次のようになります。

SAML連携しているので、一度ログインボタンを押すだけで何度も別のURLへ移動します。Cognito→IIC→Entra IDと連携を繋いでいるため、こういった挙動になります。

AgentCore Runtimeの認証

フロントエンドでの認証が通ってアプリにアクセスできたとしても、エージェントを呼び出せなければ意味がありません。

そこで、フロントエンドからAgentCore Runtime上のAIエージェントを呼び出すための処理と認証認可周りについても軽く説明しておきます。

フロントエンドは、ユーザーのCognitoアクセストークンをAgentCore RuntimeへBearer Tokenとして送ります。
Bearerは、このトークンを持っている者として扱うというHTTP送信方式です。通常、次のようなAuthorizationヘッダーに入れます。

Authorization: Bearer <access-token>

AgentCore Runtimeはインバウンド認証として、CognitoのIssuerとJWKSを基準にJWTを検証します。検証済みJWTのsubをユーザーIDとして使う形です。

具体的な作成手順としては、AgentCore Runtimeを作成する画面を開き、インバウンド認証の設定で下記を入れていきます。

設定項目	入れる値	理由など
プロトコル	HTTP	普通にAIエージェントを動かすため
インバウンド認証タイプ	JSON Web Tokens(JWT)	フロントエンドでの認証結果を使ってAIエージェントをセキュアに呼び出すため
JWTスキーマ設定	既存のIDプロバイダーの設定を使用	先ほど作成したIDプロバイダーを使うため
検出URL	https://cognito-idp.<region>.amazonaws.com/ap-northeast-1_<id>/.well-known/openid-configuration	先ほど作成したCognitoを使うため
JWT認可設定 - 許可されたクライアント	CognitoアプリクライアントのクライアントID	先ほど作成したクライアントを使うため

まとめ

これで組織向けのちゃんとした認証でAIエージェントアプリを作れるようになりました(私は)。皆さんの環境にあわせてカスタマイズして構築してみてください！