AI時代の「OAuth認証」にどう物申すか？（OAuth/OIDC Numa (Immersion) Workshop 2026）

2026/08/25 開催
OAuth/OIDC Numa (Immersion) Workshop 2026 発表資料

AI時代の「OAuth認証」にどう物申すか？

古川 英明

Transcript

1. OAuth/OIDC Numa (Immersion) Workshop 2026 AI時代の「OAuth認証」に どう物申すか？ 2026年8月25日 古川 英明
2. セッションの 流れ AI系のサービスで、OAuth 2.0での認可を 「OAuth認証」のような表現をしている例を 紹介し、この誤解をどう解くべきかを議論。 お願い IIW (Internet Identity Workshop)でのディ スカッション形式で進行するため、 質問やコメントがあれば随時挙手してください。 最後の議論にも積極的にご参加いただけると幸いです。
3. 「OAuth認証」と言えば、OAuth 2.0を用いてID連携を誤って 実装することとよく言われてきていた。 﨑村さんとritouさんそれぞれによる「OAuth認証」の誤解を解くブログ記事 出所） https://www.sakimura.org/2023/06/1087/ https://ritou.hatenablog.com/entry/2020/12/01/000000
4. Claude Codeが普及し始めた2025年半ば頃では認可の文脈で 「OAuth認証」という誤用がLLMによってされることが度々発生。 2025年6月末におけるClaude Codeに対する「OAuth認証」の誤りを指摘するやり取り（抜粋）
5. OpenAIによるMCPに関する学習ページでは、MCPサーバへの 接続方法として”OAuth authentication”と誤用している。 OpenAI公式のMCPに関する学習ページと、その中で”OAuth authentication”の表記箇所（赤枠） 出所）https://learn.chatgpt.com/docs/extend/mcp?surface=app に追記
6. AnthropicによるClaudeからのリモートMCPサーバ接続方法としても、 authentication（認証）の中にOAuth 2.0が記載されている。 Anthropic公式のリモートMCP接続方法説明ページと、その中でのOAuth 2.0を認証とするようなの表記箇所（赤枠） 出所）https://claude.com/docs/connectors/building/authentication に追記
7. リソース側としてのGemini APIに接続する際も”authentication with OAuth（「OAuthで認証」）と記載されている。 Google公式のGemini APIへの接続方法説明ページと、その中での「OAuthで認証」の表記箇所（赤枠） 出所）https://ai.google.dev/gemini-api/docs/oauth に追記
8. Copilot Developer Campでは、MCPサーバへの接続に関して 最初はOAuth 2.0の認可と記載しているが途中から認証と誤用。 Microsoft Copilot StudioでのMCPサーバへの接続方法の説明と、その中での”OAuth authentication”の表記箇所（赤枠） 出所）https://microsoft.github.io/copilot-camp/pages/make/copilot-studio/10-mcp-oauth/ に追記
9. OAuth 2.0のフローで、認可サーバによるユーザー認証があることを 以てして、全体が「OAuth認証」と誤解されている？ RFC 6749での認可コードフロー全体像 出所）RFC 6749 The OAuth 2.0 Authorization Framework
10. OAuth 2.0で「認証」の対象は認可サーバによるリソースオーナーと クライアントは明快だが、リソースサーバによるクライアントが曖昧。 RFC 6749でのリソースサーバによる クライアントの認証の記載箇所 認可コードフローを想定したOAuth 2.0の概略と、認証の箇所 ⑤リソースサーバによる 「認証」 （アクセストークン確認） ④アクセストークンを持ってリソース要求 クライアント （AIエージェント等） ⑥リソース提供 ②認可サーバによる クライアントの認証 （エンティティ認証） ①認可サーバによる リソースオーナーの認証 （エンティティ認証） リソースオーナー リソースサーバ （MCPサーバ等） ③アクセストークン発行 認可サーバ 出所）RFC 6749 The OAuth 2.0 Authorization Framework
11. OAuth 2.0で「認証」の対象は認可サーバによるリソースオーナーと クライアントは明快だが、リソースサーバによるクライアントが曖昧。 RFC 6749でのリソースサーバによる クライアントの認証の記載箇所 認可コードフローを想定したOAuth 2.0の概略と、認証の箇所 ⑤リソースサーバによる 「認証」 （アクセストークン確認） ④アクセストークンを持ってリソース要求 クライアント （AIエージェント等） リソースサーバ （MCPサーバ等） ⑥リソース提供 それでもOAuth 2.0全体はリソースオーナーからクライアントへの認可のプロトコルであって、 どのクライアントであるかをリソースサーバが識別する「認証」ではない ②認可サーバによる クライアントの認証 （エンティティ認証） ①認可サーバによる リソースオーナーの認証 （エンティティ認証） リソースオーナー ③アクセストークン発行 認可サーバ 出所）RFC 6749 The OAuth 2.0 Authorization Framework
12. 「OAuth認証」のような曖昧や誤った用語利用が 議題 広まっている今、LLMにも正しい用語利用をしてもらうように どのように行動するべきか？