OAuth 2.1とMCP｜2.0との違いと、AIエージェント時代の認可を図解で整理する🔥

Last updated at 2026-06-27Posted at 2026-06-27

OAuth 2.1 は、OAuth 2.0 で事故りやすかった使い方を仕様レベルで封じた、認可の最新仕様です。最近やたら名前を聞くのは、生成AIとツールをつなぐ標準仕様「MCP（Model Context Protocol）」が、認可方式に OAuth 2.1 を必須にしたからだ。

「OAuth 2.1って、結局2.0と何が違うん？」。そう聞かれてパッと答えられる人、自分のまわりだとあんまりいない。自分も最初はそうだった。でも要点は早見表の6つだけ。それだけ押さえれば足りる。この記事では OAuth 2.0 との違いを軸に、OAuth 2.1 を図解で整理していく。

1. そもそもOAuthとは？（30秒おさらい）

OAuth は「パスワードを渡さずに、アプリに必要な権限だけを許可する」しくみです。たとえば外部サービスに「自分のGoogleカレンダーを読む権限だけ」を渡す、あの裏側。あれがOAuthだと思えばいい。

なお「Googleでログイン」を担うのは、OAuthの上に作られた認証のしくみ OpenID Connect（OIDC）のほうです。OAuthが扱うのは権限の受け渡し、つまり認可で、ログイン（認証）とは役割が違います。ここを分けておくと、この先の話がぶれません。

登場人物は、ユーザー、アプリ、認可サーバー、API の4者。

※ 図はわかりやすさのため簡略化しています。実際の認可コードフローでは、認可サーバーはまず認可コードを返し、アプリがそれを裏側（サーバー間）でアクセストークンに交換します。トークンがユーザーのブラウザを通らないことが、安全性のポイントです。

ここでアプリに渡るのはアクセストークン、いわば一時的な鍵だ。パスワードそのものは手元から出ていかない。

2. OAuth 2.0で何が問題だったのか

OAuth 2.0（RFC 6749、2012年）は広く普及しました。でも登場から10年以上経って、安全に使うための作法が仕様の外にどんどん散らばってしまった。代表的なのがこのあたり。

Implicit グラント：トークンをURLに直接載せて返す方式。手軽だが漏えいリスクが高い。
パスワード直渡し（Resource Owner Password Credentials）：アプリにIDとパスワードを渡す方式。OAuthの理念に反する。
リダイレクトURIの曖昧な一致：なりすましサイトへトークンを横取りされる余地があった。

どれも「使うな」とベストプラクティス文書（OAuth 2.0 Security BCP）で何度も警告されてきた。でも、仕様本体を読んだだけじゃ安全に実装できない。そういう状態だったわけだ。

3. OAuth 2.1とは？「ベストプラクティスの統合版」

そこで OAuth 2.1 の登場です。「また新しい技術を覚えるのか」と身構えるかもだけど、そうじゃない。バラバラの文書に散らばってた安全な使い方を、1本の仕様にまとめ直しただけ。危ない選択肢を最初から消して、安全な道だけ残した。

補足：OAuth 2.1 は2026年時点でまだ正式な RFC ではなく、IETF のドラフト（draft-ietf-oauth-v2-1）段階です。とはいえ MCP をはじめ主要なプロダクトが事実上の標準として採用しており、実装では2.1準拠を前提に設計しておくのが安全です。

4. OAuth 2.0とOAuth 2.1の違い【早見表で図解】

2.0から何が消えて、何が必須になったのか。主だった違いを表にまとめた。どれも「事実上、認可コードフロー（Authorization Code Flow）＋PKCE を標準ルートにする」方向の変更だと思えば、見通しがいい。

項目	OAuth 2.0	OAuth 2.1
PKCE	任意（推奨）	認可コードフローでは必須（全クライアント）
Implicit グラント	あり	廃止
パスワード直渡し	あり	廃止
リダイレクトURIの照合	部分一致が可能	完全一致が必須
トークンのURL添付	可能	禁止
パブリッククライアントのリフレッシュトークン	制約ゆるめ	送信者拘束 or ワンタイム

補足：表の「送信者拘束 or ワンタイム」とは、リフレッシュトークンを使うたびに使い捨てにする（ワンタイム）か、発行された相手以外では使えなくする（送信者拘束）ことです。万一盗まれても使い回されにくくする狙いがあります。

なお、ユーザーが介在しないサーバー間連携（Client Credentials）は OAuth 2.1 でも引き続き使えます。今回廃止されたのは Implicit とパスワード直渡しです。

で、いちばん効くのが PKCE（ピクシー）の全面必須化だ。たとえばモバイルアプリだと、認可サーバーから返ってきた認可コードが、アプリに届くまでの途中で悪意ある別アプリに横取りされることがある。PKCE はこの「認可コードを途中で盗まれても悪用させない」ためのしくみで、使い捨ての合言葉をクライアントが毎回作って照合する。

※ ここでのハッシュは一方向です。ハッシュから元の合言葉は復元できないので、途中で認可コードとハッシュを盗まれても、元の合言葉を持たない攻撃者はトークンを受け取れません。これがPKCEの肝です。

OAuth 2.0 では PKCE はあくまで任意の拡張（RFC 7636）で、主にパブリッククライアント向けの推奨どまりだった。それが 2.1 では、認可コードフローを使う全クライアントで必須になる。この一点だけでも、2.1がセキュリティの底上げ版だってわかる。

5. なぜAIエージェントの標準「MCP」はOAuth 2.1を採用したのか

なんで MCP はわざわざ OAuth 2.1 を選んだのか？ AIが外部ツールを安全に触るためのしくみが要るからだ。MCP では、AIがアクセスする MCPサーバーがリソースサーバー、AI側のツールがOAuthクライアントにあたって、両方に OAuth 2.1 の枠組みを求める。

MCPクライアントの多くは、CLIツールやデスクトップアプリみたいなパブリッククライアント（秘密鍵を安全に隠せないタイプ）だ。だからこそ PKCE が必須になって、認可コードを途中で盗まれても悪用されにくくなってる。

さらに 2.1 では、トークンが自分宛てに発行されたものかを検証する、宛先（Audience）の確認が重視される。ある外部ツール向けに出したトークンを、AIが別のサーバーに使い回せないようにする歯止めだ。他人の権限を勝手に流用させないための備え、というわけ。

※ 仕様の根拠：この宛先検証は、クライアントが対象リソースを明示する RFC 8707（Resource Indicators）と、MCPサーバーが認可の要件を公開する RFC 9728（Protected Resource Metadata）に支えられています。MCPクライアントはこのメタデータから認可サーバーを発見し、対象リソース宛てのアクセストークンを取得します。

AIエージェントが外部ツールやAPIを自分で叩く時代に、誰が、何に、どこまでアクセスしていいかを安全に管理する。それを実際に回してるのが OAuth 2.1 なんだ。

6. 実務での位置づけ

新規実装は2.1準拠が前提化しつつある：認可コードフロー＋PKCE必須、Implicitとパスワード直渡しは使わない、リダイレクトURIは完全一致。新しく書くなら、最初からこの線で組んでおけば間違いない。
MCPサーバー／クライアントを書くなら：リソースサーバーとしてのトークン検証、Audience（宛先）の確認、保護リソースメタデータ（RFC 9728）の公開まで意識する。ここまでやって、ようやく仕様どおりだ。
2.0を知ってれば差分で追える：丸ごと覚え直す必要はない。「何が廃止されて、何が必須になったか」さえ押さえれば、たいていの認可フローは読める。

7. まとめ

OAuth 2.1 は、2.0に散らばってた安全策を1つに束ね、危ない選択肢を仕様レベルで消した認可の最新仕様（PKCE必須、Implicitとパスワード直渡しは廃止、など）。
まだ IETF のドラフト段階。でも MCP をはじめ主要プロダクトがもう事実上の標準として採用してるので、実装では前提扱いにしておくのが安全だ。
AIエージェントが外部ツールを自分で扱う時代の、アクセス管理のかなめになる技術。

まずは早見表の6点。認可コードフロー＋PKCE を軸に、あとは個別の仕様を差分で足していけばいい。

参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up