OAuth2

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration（DCR）対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群（9728 / 8414 / 9068 / 8707 / 7636）の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか（RFC 7591 / 9728 / 8414 の連動） Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか（RFC 9068 / 8707 と DCR の構造的な相性問題） なぜ MCP では Dynamic Client Registration（DCR）が必要なのか 従来の OAuth 2.0（RFC 6749）は、クライアント（アプリ）を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

個人開発アプリを MCP 化しようとして、認証の壁に阻まれた経験はないだろうか。 大手 SaaS が次々と MCP を公開する今、個人開発者も「自分のアプリを MCP で叩けるようにしたい」と思うのは自然な流れだ。 しかし認証の設計は想像以上に重い。 この記事では、WorkOS AuthKit を使えば MCP 認証（OAuth 2.0 Dynamic Client Registration 対応）を Next.js で 30 分・50 行以内に実装できる理由と具体的な手順を紹介する。 MCP 化の波が押し寄せている ここ数ヶ月で、Notion・Linear・Stripe・Vercel・Cloudflare など、ちょっと触っているサービスはほぼ間違いなく MCP を出している印象だ。 Claude Code や Cursor に登録すれば、「自分の Notion を読んで」「Linear に issue を立てて」が自然言語で動く。 個人開発者にとっても無視できない流れだ。 自分の作ったアプリも、CLI だけじゃなく MCP で叩けるようにしておくと、ユーザー体験が一段別物になる。 認証の壁 いざ自作アプリを MCP 化しようとすると、ほぼ全員がここで止まる。 「Bearer トークンを受け取って検証する」と書くと一行だが、実際には： ユーザーごとにアクセストークンを発行する仕組み Claude Code などのクライアント側がトークンをどう取得するか（OAuth？API キー手動コピペ？） トークンをどう保存・更新するか（リフレッシュトークン、有効期限…） 複数クライアントから同じユーザーが繋ぐ場合の扱い これを真面目に作ると、週末が溶ける。筆者（html-to-pptx 作者）も最初は自前で API キー方式を実装していたが、「MCP クライアントから自動でログインさせたい」と思った瞬間、設計が一気に重くなることに気づいた。 結論：WorkOS（AuthKit）を使え タイトルにも書いたが、もう一度言う。個人開発者が MCP 化するなら、WorkOS の AuthKit 一択だ。 B2B 向けのサービス展開を考えている場合も、その場合も WorkOS が特におすすめだ。 ...

AI エージェントが外部ツールやデータソースに安全にアクセスするための標準プロトコル「MCP（Model Context Protocol）」が、OAuth 2.1 ベースの認証・認可フレームワークを導入し、エンタープライズ環境での採用が加速しています。本記事では、MCP の認可仕様の仕組みと、企業導入における設計ポイントを解説します。 MCP とは MCP（Model Context Protocol）は、AI アシスタントがツール、データソース、サービスといった外部リソースに接続するための標準プロトコルです。Anthropic が提唱し、オープンな仕様として公開されています。 MCP を使うことで、AI エージェントは以下のようなことが可能になります： 社内データベースへのクエリ実行 外部 API の呼び出し ファイルシステムの操作 各種 SaaS サービスとの連携 OAuth 2.0 から 2.1 へ：何が変わったのか OAuth 2.1 は OAuth 2.0 の後継仕様であり、これまで個別の RFC やベストプラクティスとして散在していたセキュリティ強化策を統合したものです。MCP がベースとする OAuth 2.1 では、以下の重要な変更が含まれています： 変更点 内容 PKCE 必須化 全クライアント（パブリック・コンフィデンシャル両方）で必須に Implicit フロー廃止 アクセストークンが URL フラグメントに露出するリスクを排除 リフレッシュトークンのローテーション パブリッククライアントでのトークン漏洩時の影響を軽減 リダイレクト URI の厳密一致 ワイルドカードによるオープンリダイレクト攻撃を防止 つまり、OAuth 2.1 は「新機能の追加」というより、OAuth 2.0 時代に発見された攻撃手法への対策を標準に組み込んだものです。 MCP の認可アーキテクチャ MCP の認可仕様では、OAuth 2.1 をベースに、AI エージェント特有の要件に対応した複数の仕組みを組み合わせています。 ...