仕様と現実の間で落とし所を探るリモートMCPの認証・認可 — Sansanの認証基盤における課題と実践

■イベント
OpenID TechNight vol.24 ~ SSF × AIdentity
https://openid.connpass.com/event/409691/

■登壇概要
タイトル：仕様と現実の間で落とし所を探るリモートMCPの認証・認可 — Sansanの認証基盤における課題と実践
登壇者：技術本部 Platform Engineering Unit Identity Platformグループ 輿石一輝、都筑一希

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Sansan技術本部 仕様と現実の間で落とし所を探る リモートMCPの認証‧認可 — Sansanの認証基盤における課題と実践 Sansan株式会社 技術本部 Platform Engineering Unit Identity Platformグループ 輿⽯⼀輝 / 都筑⼀希
2. 輿⽯⼀輝（Itsuki Koshiishi） 技術本部 Platform Engineering Unit Identity Platform グループ 2026年にSansan株式会社へ新卒⼊社。 共通認証基盤「Auth One」の開発‧運⽤を担当。 OAuth/OIDCを中⼼とした認証‧認可に携わり、M2M認証認可‧APIの レート制限‧OAuth/OIDCライブラリの内製化などに取り組んでいる。
3. Sansan株式会社の働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 法⼈向け 個⼈向け 名刺データベースが、収益を最⼤化する 契約データベースが、利益を守る 「なくせる」をつくり、全社の働き⽅を変える 営業AXサービス 契約AXサービス 経理AXサービス 名刺アプリ 営業 契約 請求 名刺 管理 顧客マスターマネジメント 各サービスの活⽤で変わる働き⽅ 必要な情報を 情報の管理がしやすく 情報を分析‧活⽤しやすく すぐに⾒つけられる すぐに共有できる データに基づいた判断ができる
4. OIDF-J加⼊
5. アジェンダ - 前半（輿⽯） > MCPのSpecを元にクライアント登録とクライアント認証 > CIMDとPrivate Key JWTに関して - 後半（都筑） > 共通認証基盤Auth Oneについて > Contract One MCPサーバー提供時の課題‧実践
6. 前半アジェンダ - MCPの概要 - クライアント登録 - CIMDの詳細 - MCPサーバーのセキュリティ
7. MCPとは
8. MCPとは - Model Context Protocol(MCP) とは > AIアプリケーションを外部システムに接続することを⽬的としてAnthropic社 が公開したオープンプロトコル > AI Agentが別のサービスを呼び出す際に⽤いられる MCPクライアント MCP MCPサーバー ツール 7
9. MCPにおける認証認可 - リモート MCP サーバー の保護されたデータにアクセスするための認可⽅式として、MCP では OAuth を⽤いる⽅法が標準化されている > https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization MCP クライアント (OAuthクライアント) ChatGPT 認可サーバー 認可リクエスト アクセストークン Claude Copilot MCP サーバー ( リソースサーバー)
10. MCPにおける認証認可 課題：多様な MCP クライアント をどう登録‧管理するか？ OAuth クライアント MCP クライアント ChatGPT Claude Copilot 認可サーバー ( Authorization サーバー ) ‧‧‧
11. クライアント登録
12. クライアント登録⽅式 - 静的登録(Pre-registration) - 動的登録 > CIMD > DCR - https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration 静的登録 CIMD ＞ DCR
13. 静的登録 - 認可サーバーにOAuthクライアントを事前登録する > 通常のOAuth クライアント作成と同様 - メリット > 認可サーバー提供者：追加実装する必要がない > MCP サーバー提供者：認可サーバーの実装状況に依存せず提供ができる - デメリット > MCPクライアントごとに登録‧変更する運⽤が必要
14. DCR（Dynamic Client Registration） - 以前からオープンバンキングなどで利⽤されていたクライアント登録⽅式 - 認可サーバーが登録エンドポイントを公開し、クライアントが⾃⾝の情報を送信し て登録する - MCP 2025-03-26‧2025-06-18 でSHOULD →MCP 2026-07-28 ⾮推奨
15. DCRの難しさ - リクエスト元を検証する⽅法が存在しないためOAuthクライアントを誰でも作成可能 > Initial Access Tokenを利⽤するクライアントは存在しない > リクエスト元のIPで⼀定絞れそうだが、Microsoft 365 CopilotはIPレンジを公開し ていない - 公開していたとしてもIPの定期的な更新運⽤が必要 - 作成された⼤量のクライアントの棚卸し運⽤を実施する必要あり > 正規利⽤でも⼤量にクライアントが作成される可能性あり - ⼀定期間利⽤されていないクライアントの定期的な削除などが必要 14
16. CIMD（Client ID Metadata Document) - クライアント情報を配信するURLをクライアントIDとして扱う - 認可サーバーは、認可リクエストの クライアントIDからメタデータを取得する - 取得したメタデータを検証し、認証‧認可を進める - MCP 2025-11-25 以降ではサポートを推奨
17. DCR と⽐較した CIMD の利点 - クライアント数が減る > MCPクライアント単位で1つのURLをクライアントIDとして宣⾔する仕組み > 認可サーバーはOAuthクライアント数がMCPクライアント数になる - リクエスト元の検証が不要となる > 認可サーバーから、MCPクライアントにリクエストをする⽅式のため認可サー バーが制御
18. CIMDの詳細
19. CIMD(Client ID Metadata Document)
20. CIMD(Client ID Metadata Document) { "client_id": "https://chatgpt.com/oauth/client.json", "client_uri": "https://chatgpt.com/", "redirect_uris": ["https://chatgpt.com/connector_platform_oauth_redirect"], "token_endpoint_auth_method": "private_key_jwt", "token_endpoint_auth_methods_supported": ["none", "private_key_jwt"], "grant_types": ["authorization_code", "refresh_token"], "response_types": ["code"], "client_name": "ChatGPT", "logo_uri": "https://persistent.oaistatic.com/sonic/misc/openai-logo.png", "token_endpoint_auth_signing_alg": "RS256", "jwks_uri": "https://chatgpt.com/oauth/jwks.json" }
21. クライアント認証⽅式 クライアント認証⽅式 サポート状況 none Public Clientでサポート client_secret_basic 共有シークレットを使うため禁⽌ client_secret_post 共有シークレットを使うため禁⽌ private_key_jwt Confidential Clientでサポート CIMD は公開されるため、OAuthクライアントと認可サーバーだけが知るシークレッ トを安全に共有できない
22. クライアントの実装状況 MCPクライアント Claude ChatGPT Microsoft 365 Copilot CIMD対応状況 サポート済み サポート済み 未サポート クライアント 認証方式 none none, private_key_jwt -
23. Private Key JWT - 公開鍵暗号⽅式を利⽤したクライアント認証⽅式 - クライアントが秘密鍵で署名した JWT を、メタデータから取得した公開鍵で検 証する 秘密鍵 秘密鍵で署名した JWT クライアント 認可サーバー 公開鍵を取得 公開鍵エンドポイント
24. Private Key JWT - 通常のOAuthのフローに組み込んだ > 認可コードフロー > Auth Oneの管理APIのClient Credentials Grant - 採⽤の背景 > 署名鍵の管理‧署名にKMSを利⽤する > ローテーションが可能
25. パブリッククライアントの受け⼊れ - CIMD と private_key_jwt を組み合わせ、クライアント認証を⾏いたい > 対応しているMCPクライアントが少ない - パブリッククライアントも受け⼊れ、不正利⽤のリスクを抑える対策を⾏う
26. セキュリティ考慮事項
27. CIMDのセキュリティ考慮 - CIMD では、認可サーバーがクライアント指定の URL からメタデータを取得する > 取得処理を悪⽤されないための対策が必要 - SSRF対策 > 許可ドメインの設定‧制限 > 接続先IPアドレスの検証 - リソース消費攻撃への対策 > レスポンスサイズの制限 > レートリミット
28. パブリッククライアントの保護 OAuth2.1のプラクティスを利⽤する - PKCE - リフレッシュトークンのローテーション - リダイレクトURIの厳密な検証 - DPoP > https://modelcontextprotocol.io/development/roadmap#3-agent-identity-and-enterprise-ready-security
29. まとめ - MCPの認可はSpecificationが存在しOAuth2.1準拠 - クライアント登録⽅法の選定⽅法もSpecに記載 > CIMDと静的登録が推奨、DCRは⾮推奨 - CIMD > private_key_jwtとパブリッククライアントが可能 > 利⽤可能なMCPクライアントにはPrivate Key JWTを利⽤ - OAuth 2.1 に沿ったセキュリティ対策と、CIMD の外部取得への対策を⾏う
30. 都筑 ⼀希（Kazuki Tsuzuku） 技術本部 Platform Engineering Unit Identity Platform グループ ヤフー株式会社にてID連携プロダクトを担当。 iOSのログインSDKや認可サーバーのバックエンド開発を経験。 Sansan株式会社では共通認証基盤「Auth One」の開発‧運⽤を担当。
31. 後半アジェンダ - Auth Oneの成り⽴ちとプロダクトとの責務分離 - Contract One MCPサーバーの概要 - MCPサーバー提供時の検討事項 > MCPサーバー提供⽅法 > OAuthクライアント登録⽅法 > 複数テナント対応 30
32. Auth Oneの成り⽴ちとプロダクトとの責務分離
33. Auth Oneの成り⽴ち - Bill Oneで利⽤していたAuth0をコスト削減のため内製化 - プロダクトごとのテナント管理や権限管理はプロダクトで実装 - 今では複数のプロダクトで利⽤されている共通認証基盤へ 32
34. Auth Oneとプロダクトの責務分離 Auth One管理の認証 プロダクト Auth One テナント パスワード MFA システム管理者 OIDC SSO 経理担当 経理担当 契約管理者 OIDC Auth Oneではプロダクトの テナント情報を持たない SAML 33
35. Contract One MCPサーバーの概要
36. Contract OneのAI活⽤機能 https://jp.corp-sansan.com/news/2026/0420.html https://jp.corp-sansan.com/news/2026/0817.html Sansan株式会社「 Contract One、MCPサーバーの提供を開始」 Sansan株式会社「契約 AXサービス『 Contract One』が『AIエージェント Powered by Claude』機能の提供を開始」 （2026年4月20日発表） （2026年8月17日発表） 35
37. Contract One MCPサーバー利⽤想定対象 - 利⽤想定職種 > 法務‧契約実務者 - 多数のユーザーは1テナントに所属 - 少数のユーザーは複数テナントに所属 - 利⽤想定MCPクライアント > Claude Desktop, ChatGPT, Microsoft 365 Copilot - 提供⽅法 > リモートMCPサーバー 36
38. MCPクライアントとMCPサーバーの接続種別 クライアント直接型 MCPサーバー MCPクライアント OAuthクライアント動作環境: MCPクライアント動作環境 Redirect URI: localhost 代表例: Claude Code, Codex, VSCode 認可サーバー バックエンド仲介型 MCPサーバー MCPクライアント MCPクライアント バックエンド OAuthクライアント動作環境: バックエンド Redirect URI: バックエンド 代表例: Claude Desktop, ChatGPT, Microsoft 365 Copilot 認可サーバー 37
39. Contract One MCPサーバー提供に関する検討事項
40. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 - OAuthクライアントの登録⽅法 - 複数テナント所属ユーザーにおける課題 39
41. MCPサーバーの設定種別 設定種別 個⼈設定 テナント設定 プラットフォーム掲載 設定者 MCPサーバー利⽤者 MCPサーバー利⽤テナント システム管理者 MCPサーバー提供者 OAuthクライアント 発⾏単位 個⼈ or テナント単位 テナント単位 or プラットフォーム単位 プラットフォーム単位 - 個⼈ごとに設定が必要なので導⼊ 時の運⽤コストが⾼い - テナントごとの設定のため個⼈設定 に⽐べ導⼊コストが低い - OAuthクライアント数も多く運⽤ コストが⾼い - CIMDを活⽤して発⾏単位を プラットフォームにすることも可能 特徴 現状採⽤ - 設定作業がMCPサーバー提供者 で完結し、OAuthクライアントも 少なく済む - 各プラットフォームの審査が必要 理想的な設定⽅法 40
42. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 > 今はテナント設定、今後はプラットフォーム掲載で導⼊コスト‧運⽤負荷軽減 - OAuthクライアントの登録⽅法 - 複数テナント所属ユーザーにおける課題 41
43. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 > 今はテナント設定、今後はプラットフォーム掲載で導⼊コスト‧運⽤負荷軽減 - OAuthクライアントの登録⽅法 - 複数テナント所属ユーザーにおける課題 42
44. OAuthクライアントの登録⽅法 - まずは静的登録から運⽤開始 - 今後はCIMDの利⽤を想定して実装‧MCPクライアントの対応状況確認 - DCRは可能な限り採⽤しない 43
45. 各プラットフォームでのCIMDの特徴 項⽬ / プラットフォーム Claude ChatGPT Microsoft 365 Copilot サポート状況 サポート済み サポート済み 未サポート OAuth クライアント認証種別 none none, private_key_jwt - CIMD利⽤時に認可サーバーが検討すべき内容 - メタデータの更新ポリシー > redirect_uri, token_endpoint_auth_methods_supportedなどが変わった時にどうするかは 認可サーバーに委ねられている - メタデータ以外のカスタム項⽬ > メタデータには含まれない独⾃の設定項⽬（トークン有効期間、SSO設定など）を プロダクトごとの要件に合わせて設定可能にする 44
46. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 > 今はテナント設定、今後はプラットフォーム掲載で導⼊コスト‧運⽤負荷軽減 - OAuthクライアントの登録⽅法 > 今は静的登録、今後は徐々にCIMDへ - CIMDを実際に導⼊する際にはメタデータ更新や、カスタムポリシーなどを考慮する - 複数テナント所属ユーザーにおける課題 45
47. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 > 今はテナント設定、今後はプラットフォーム掲載で導⼊コスト‧運⽤負荷軽減 - OAuthクライアントの登録⽅法 > 今は静的登録、今後は徐々にCIMDへ - CIMDを実際に導⼊する際にはメタデータ更新や、カスタムポリシーなどを考慮する - 複数テナント所属ユーザーにおける課題 46
48. 現在の複数テナントユーザーのテナント切り替え⽅法 Auth One テナントA 所属 テナントB MCPクライアント Contract One OAuthクライアント テナントA OAuthクライアント テナントB Contract One MCP テナントA /tenants/tenant-A/mcp Contract One MCP テナントB /tenants/tenant-B/mcp 権限制御は引き続き Contract Oneで検証 MCPサーバー https://mcp.contract-one.com ユーザーはMCPクライアントで 利⽤するMCPサーバーを テナントごとに切り替え MCPサーバーはURLのパスで 操作対象のテナントを特定
49. プラットフォーム掲載型での課題 MCPクライアント プラットフォーム テナントA 所属 テナントB MCPクライアント テナントA 所属 テナントC 所属 MCPクライアント MCPクライアント Contract One MCP Contract One MCP Auth One OAuthクライアント Contract One Contract One MCP Contract One MCP https://mcp.contract-one.com/mcp MCPサーバーはURLのパスで 操作対象のテナントを特定できない MCPサーバー https://mcp.contract-one.com
50. プラットフォーム掲載型でのテナント識別⽅法検討案 Auth One Contract One テナント選択画⾯ ログイン テナントA 所属 テナントB 権限制御 ✅ テナントA テナントB MCPサーバー https://mcp.contract-one.com Auth Oneは ユーザーの所属テナントを認識し 操作対象のテナントを選択させる アクセストークン テナントA MCPサーバーは アクセストークンのクレームから 操作対象のテナントを特定する
51. Contract One MCPサーバー提供に関する検討事項 - MCPサーバーの設定⽅法 > 今はテナント設定、今後はプラットフォーム掲載で導⼊コスト‧運⽤負荷軽減 - OAuthクライアントの登録⽅法 > 今は静的登録、今後は徐々にCIMDへ - CIMDを実際に導⼊する際にはメタデータ更新や、カスタムポリシーなどを考慮する - 複数テナント所属ユーザーにおける課題 > プラットフォーム掲載時には複数テナント所属ユーザーの操作対象テナントの識別に課題 - Auth Oneにテナント管理機能を持たせ、ユーザーに利⽤テナントを選択してもらい アクセストークンに選択したテナントの識別⼦を含める⽅針で検討中 50