こんにちは、ネクストモード株式会社テクニカルサポート担当です。
2026年8月24日、Okta は Agent SSO の一般提供を発表しました。位置づけは、新しいエージェント専用製品というより、すでに多くの組織が使っている 基本 SSO プラン への同梱 です。Cross App Access（XAA）に対応した AI エージェントを、従業員と同じ Universal Directory 上のアイデンティティとして扱い、接続の判断を各アプリの同意画面ではなく IdP 側へ移す、というのが Okta 公式の案内です。
これまで当ブログでは、Okta for AI Agents を題材に、Amazon Bedrock AgentCore の取り込みやトークン交換、Slack MCP、Notion MCP を検証してきました。今回は、Okta for AI Agents 未契約の Okta 環境で、基本 SSO プランの Agent SSO から Slack MCP へ接続できるかを検証します。
以前の Slack MCP × STS では Brokered Consent（STS）で進めていました。今回は同じ Slack MCP を ID-JAG（XAA） で確認しています。経路が分かれた理由は、後述します。
※本記事は執筆時点の情報に基づきます。画面や契約条件は Okta org のプランによって異なります。最新情報は公式ドキュメントをご確認ください。また、確認をした Okta バージョンは 2026.08.4 です。
基本 SSO プランでも、Bot トークンをエージェントへ保存せずに、Slack の公開チャンネルを読み取れました。
その確認のために実施した内容は、次のとおりです。
id_token から Okta の Org Authorization Server で ID-JAG を発行し、Slack の token エンドポイントへ jwt-bearer で渡す#dev-public の履歴を実際に読ませる「呼べた／呼べない」だけだと味気ないので、読めた中身が本物の Slack であることを同じ検証のなかで揃える、というのが今回のゴールです。
構成は Slack MCP + 基本 SSO プランの Agent SSO（XAA） です。Okta for AI Agents 未契約の Okta 環境に自作エージェントを登録し、Slack 側は Slack Enterprise の Sandbox 環境で、アプリ設定からトークン交換、公開チャンネルの読み取りまでを検証しました。
エージェントは https://mcp.slack.com/mcp を、XAA で受け取った Slack access token だけで呼びます。xoxb-... のような Bot Token は常設しません。トークンの最終発行は Slack 側の認可サーバです。
流れは次のとおりです。
id_token を得るoauth.v2.user.access へ grant_type=jwt-bearer で渡し、Slack access token を得る応答画面は、同じエージェントをローカルのチャットから呼び出した結果です。
前回の Slack MCP 記事 では STS（Brokered Consent） を選びました。今回は同じ Slack MCP を ID-JAG（Cross App Access） で確認しています。経路が分かれた理由は、次の 2 点です。
ポイントは、エージェントが ID-JAG を渡す相手です。ID-JAG を受け取るのは Okta ではなく、接続先 MCP の認可サーバです。そのため、接続先の認可サーバが ID-JAG に対応しているかを .well-known/oauth-authorization-server で確認します。見るポイントは次の 2 つです。
前回の執筆時点では、Slack MCP の metadata に jwt-bearer も id-jag もありませんでした。grant_types_supported は authorization_code と refresh_token だけでした。公開されている認可の手順に合わせて STS で進めたため、初回は同意画面が出ました。
今回の再取得では、同じ metadata に jwt-bearer と id-jag が載っています。token_endpoint は今も https://slack.com/api/oauth.v2.user.access です。加えて、今回の Okta org は基本 SSO プラン の Agent SSO で、Slack アプリ統合の Resource server に STS は出ません。ACCESS METHODS は XAA のみです。
この 2 点から、今回は ID-JAG を Slack へ渡す XAA で確認しています。チャット経路では同意画面は出ていません。OIN に Cross App Access と書いてあっても、接続先が実際に受け取る grant と同じとは限らない、というのは前回と同じです。中身は後から変わります。公開済みの STS 記事は、当時の事実のままです。
発表資料の対比 は、次のとおりです。
| Agent SSO（基本 SSO プラン） | Okta for AI Agents | |
|---|---|---|
| 対象エージェント | Cross App Access を話すもの | 構築場所を問わず |
| Where are my agents? | XAA 対応エージェントを Universal Directory に登録 | シャドー AI を含む全エージェントの発見・登録 |
| What can they connect to? | XAA 経由の agent-to-app 接続（短命トークン） | 非 XAA、agent-to-agent、ランタイム強制などへ拡張 |
| What can they do? | 対象外（N/A） | 認定、高度な認可、kill switch |
Agent SSO が担うのは、XAA に対応した AI エージェントを、アプリや MCP へ安全に接続するための仕組みです。今回は、自作エージェントから Slack MCP へ接続し、基本 SSO プランでどこまで利用できるかを確認しました。
実際の管理画面でも、プランによる機能の違いを確認できました。今回使用した基本 SSO プランでは、Slack への接続方法として表示されたのは XAA のみです。上位プランの Okta for AI Agents で利用できる STS や Machine access は表示されませんでした。これは設定の不備ではなく、基本 SSO プランで利用できる機能の範囲によるものです。
なお、将来 Okta for AI Agents へアップグレードしても、Agent SSO で登録したエージェントを登録し直す必要はないと案内されています。まずは基本 SSO プランで安全な接続を始め、必要になった段階で、同じエージェントの登録情報を活かしながら管理・統制機能を追加できます。
XAA で仲介するにしても、Slack 側には OAuth クライアント（アプリ）が必要です。今回特に有効だったのは、スコープそのものより Slack 組織向けの準備でした。
channels:history と channels:read を付けます。今回は読取確認用に users.profile:read も付けています。Bot Token スコープは空のままで進めています。iss と一致している必要があります。invalid_grant_type で落ちました。remote Slack MCP を使う場合、Slack アプリの Assistant 設定で MCP server access を有効にする必要もありました。ここがオフだと、トークン交換は成功しても MCP 側が拒否します。
ここからが今回の検証の本編です。Okta Admin Console で自作エージェントを登録し、Slack 向けの Resource server（XAA）と Resource connections を設定します。
補足： Resource server タブは Sign On 方式に依存します。Slack を SWA の場合ではタブ自体が出ません。SAML にするとタブが出て、XAA を Enable できます。
役割を先に整理すると、次のようになります。
id_token を出すアプリ。エージェントと Client ID / 鍵を共有する。Client secret は無いAgent SSO にしています。http://localhost:8765/callback）を設定します。Agent SSO を開くと User access にチェックがついています。
連動 OIDC アプリケーションにアサインしたユーザーとしてサインインし、チャット UI から公開チャンネル #dev-public の直近履歴を読むよう依頼しました。
以前の STS 検証では、初回に Slack の同意画面が出ました。今回の XAA 経路では、その同意画面は出ていません。
MCP の呼び出しが成功しただけでは、実際に Slack の投稿を取得できているかまでは判断できません。そこで、公開チャンネル #dev-public を対象に、エージェントから最新の投稿と直近の要約を取得できるか確認しました。応答にはチャンネル情報と実際のメッセージが含まれており、Slack 側のデータを参照できていることを確認できました。
今回の検証で確認できたポイントは、次の 3 点です。
#dev-public の履歴を同意画面なしで読み取れました
今回は、すでに Okta SSO を使っている管理者向けに、Agent SSO で何ができるかを Slack MCP で確認しました。エージェントには Bot Token を置かず、コア SSO の Cross App Access で発行される access token だけで remote Slack MCP を呼び、公開チャンネル #dev-public を読めることを確認しています。Okta for AI Agents は、この経路には不要でした。
ここで効いていたのは、AWS 側の設定ではなく、自作エージェントの Slack Resource connection と、Slack アプリ側の org-readiness / Enterprise-managed authorization でした。初回の同意画面は出ていません。
できないこと、あるいは今回確認していないことは、シャドー AI の発見、同意ありの STS、接続を切ったときの拒否、認定や kill switch といったガバナンスです。入口としてはコア SSO で足りる組織もあるはずです。エージェントの台帳や STS、接続先ごとのガバナンスまで必要になったら、Okta for AI Agents の検討へ進めましょう。
AI エージェントのアイデンティティ管理やセキュリティ統制に関するご相談は、ネクストモードまでお気軽にお問い合わせください。