OAuthとは？仕組み・認証との違い・危険性と対策をわかりやすく解説

最終更新日:2026/08/12

「Googleでログイン」や「カレンダーへのアクセスを許可」と表示されたとき、裏側では認証と認可という別の仕組みが動いています。OAuthは、パスワードを連携先へ渡さず、必要なデータへのアクセス権だけを委ねる認可の標準仕様です。

本記事では、OAuth 2.0の仕組みと認可コードフロー、OpenID Connectとの違い、RFC 9700に沿った安全対策を図解します。さらに、情シスが行うOAuthアプリ管理と、MCPによるAIエージェント連携の確認点まで、2026年8月時点の仕様に基づいて解説します。

OAuth（オーオース）とは？認可の仕組みをわかりやすく解説

OAuthとは、パスワードを連携先へ渡さず、特定のデータや機能へのアクセス権だけを第三者のアプリへ委ねる認可の標準仕様です。読み方は「オーオース」。現在の事実上の標準は、2012年に発行されたOAuth 2.0（RFC 6749）です。

OAuthは「認証」ではなく「認可」の標準仕様

最初に押さえたいのは、OAuthが決めるのは「何を許すか」であって「誰か」ではないという点です。

利用者が本人かどうかを確かめる行為は「認証」。その利用者やアプリに対して、どのデータ・どの機能まで触ってよいかを決める行為が「認可」です。OAuthは後者だけを担当します。この線引きを曖昧にしたまま実装すると、後述するなりすましのリスクにつながるため注意してください。

認証と認可の違いについては、後述の「認証と認可の違い｜OAuthが担うのはどちらか」で詳しく説明します。

OAuthはOpen Authorizationの略なのか

OAuthは認可のためのオープンな標準仕様です。「Open Authorizationの略」と説明されることもありますが、RFC 6749をはじめとする仕様書に、OAuthという名称の正式な展開形は定義されていません。

OAuthでできることの具体例

カレンダー連携ツール：Googleカレンダーの「閲覧」だけを許可し、編集は許可しない
SNS投稿予約ツール：XやFacebookなどのSNSへ投稿する権限だけを渡し、メッセージや連絡先へのアクセスは許可しない
会計SaaS：銀行明細の取得だけを許可し、送金機能には触らせない
AIアシスタント：社内ドキュメントの読み取りだけを許可する

共通しているのは、ユーザーがパスワードそのものを相手に渡していないという点。渡しているのは「アクセストークン」という、期限と範囲が限定された引換券にあたるものだけです。

「OAuth認証」という表現が使われる理由

一般に「OAuth認証」と呼ばれているものの実体は、OAuthを土台にしたID連携、いわゆるソーシャルログインです。OAuth自体は認可の仕組みであり、本人確認のために設計されたものではありません。ではログイン機能はどう作るべきなのか。その答えは次章で説明します。

OAuthが必要とされた背景｜パスワードを預ける方式の問題

OAuthが登場する前は、連携先に自分のIDとパスワードをそのまま預ける方式が使われていました。しかしこの方式には、深刻な問題が4つあります。

パスワードが第三者に保管される：平文保存などのリスクが残る
必要以上の権限まで渡る：「予定を読みたいだけ」でもアカウント全体を操作できてしまう
連携をやめる手段がパスワード変更しかない：ほかの連携もまとめて切れる
連携先の漏えいが本体アカウントに波及する：一箇所の事故が全体の被害に直結する

これらを解決するために設計されたのがOAuthです。パスワードの受け渡しを、期限と範囲が限定されたアクセストークンの受け渡しに置き換えました。

OAuth 1.0は2007年10月にコミュニティ仕様として安定版となり、2010年にRFC 5849として文書化されています。その後、実装の複雑さを整理した後継として、2012年にOAuth 2.0（RFC 6749）が発行されました。

出典：The OAuth 1.0 Protocol（RFC 5849）｜RFC Editor／The OAuth 2.0 Authorization Framework（RFC 6749）｜RFC Editor

認証と認可の違い｜OAuthが担うのはどちらか

認証は利用者が誰かを確認する仕組み、認可は利用者やアプリに何を許可するかを決める仕組みです。OAuthが扱うのは認可です。

認証は「誰か」、認可は「何を許すか」

比較項目	認証（Authentication）	認可（Authorization）
確認すること	本人かどうか	何を許可するか
身近な例	社員証で本人確認をする	入室できる部屋を決める
代表的な仕様	OpenID Connect、SAML	OAuth 2.0
結果として渡るもの	IDトークンなどの本人証明	アクセストークン

オフィスビルに例えると、受付で社員証を提示して本人だと確かめるのが認証、その社員証で入れる部屋がフロアごとに決まっているのが認可。OAuthが担うのは後者、つまり「どの部屋の鍵を渡すか」の部分です。

OAuthだけでログイン機能を作ってはいけない理由

ここは、OAuth実装で混同しやすいポイントです。

アクセストークンは「このトークンの持ち主に、この範囲の操作を許可する」ことを示すもの。「誰のものか」を証明する目的では設計されていません。アクセストークンを本人確認の根拠として扱うと、トークンの発行先や対象利用者を適切に検証できず、別のクライアントや用途向けに発行されたトークンを悪用されるおそれがあります。

ログイン機能には、本人確認用のIDトークンと、その検証方法まで定めたOpenID Connectを使用してください。認証と認可の混同は、用語の問題ではなく実際の脆弱性につながります。

出典：RFC 6749 Section 1｜RFC Editor／OpenID Connect Core 1.0｜OpenID Foundation

OAuthの仕組み｜4つの登場人物と認可コードフロー

OAuthは、4者の役割分担とアクセストークンの受け渡しによって成り立っています。仕組みを理解すれば、同意画面で何が起きているのかが具体的に見えてきます。

4つの登場人物（ロール）

役割	呼び方	具体例
データの持ち主	リソースオーナー	利用者本人
データを使いたいアプリ	クライアント	予定調整ツール、AIアシスタント
許可を出す窓口	認可サーバー	Googleのログイン・同意画面
データを持つサーバー	リソースサーバー	GoogleカレンダーのAPI

ここで言う「クライアント」は、パソコンやスマホという意味ではありません。データを使わせてほしい側のアプリケーションを指す用語です。

認可コードフローの6ステップ

もっとも標準的な「認可コードフロー」の流れは次のとおりです。

利用者がアプリの画面で「Googleと連携」を押す
アプリが、必要な権限の範囲（スコープ）を添えて利用者を認可サーバーへ送る
認可サーバーの画面で利用者がログインし、同意画面の内容を確認して許可する
認可サーバーが、事前に登録されたリダイレクトURLへ認可コードを返す
アプリが、その認可コードをアクセストークンと交換する
アプリがアクセストークンを付けて、リソースサーバーへデータをリクエストする

利用者から見えるのは1と3だけ。残りの処理は、アプリと各サーバーの間で自動的に進みます。

認可コードを挟む理由

なぜ一度、認可コードを経由するのでしょうか。理由は、アクセストークンをブラウザの画面遷移に露出させないためです。

画面遷移のURLは、ブラウザ履歴やサーバーのアクセスログに残ります。ここにアクセストークンが載っていれば、そのまま漏えい経路になりかねません。

認可コードは短時間で失効し、一度しか使用できません。さらに現在の標準的な実装では、後述するPKCEのコードベリファイアや、必要に応じてクライアント認証を確認してからアクセストークンへ交換します。

アクセストークン・リフレッシュトークン・スコープ

アクセストークンは、特定のリソースへアクセスするための「入館証」に相当するもの。漏えい時の被害を抑えるため、一般に有効期限を短く設定します。

リフレッシュトークンは、期限切れのアクセストークンを再発行するための引換券。盗まれた場合の影響が長期化するため、保管方法には特に注意が必要です。

スコープは、「カレンダーの閲覧だけ」のように権限の範囲を指定する仕組みを指します。最小権限の原則、つまり必要な範囲だけを渡すという考え方が、OAuthの安全性を支える中心にあります。同意画面に並ぶ「〜へのアクセスを許可します」の一覧が、まさにこのスコープです。

出典：RFC 6749 Section 1.2｜RFC Editor／Microsoft ID プラットフォームと OAuth 2.0 認証コードフロー｜Microsoft Learn

OAuth 2.0の主な認可フローと使い分け

OAuthには複数の認可フロー（グラント）があり、用途によって選ぶものが変わります。利用者が関与するWeb・モバイル連携では、認可コードフロー＋PKCEが中心です。利用者が介在しないサーバー間連携ではクライアントクレデンシャル、入力が難しい機器ではデバイス認可フローを使います。

利用者が関与する連携｜認可コードフロー＋PKCE

Webアプリ、スマホアプリ、SPA（シングルページアプリケーション）のいずれでも、基本はこの組み合わせになります。

PKCE（ピクシー）とは、認可コードを途中で横取りされても悪用できないようにする仕組み。アプリ側が秘密の文字列を作り、その要約だけを認可サーバーへ預けておきます。トークンと交換する段階で元の文字列を提示させることで、コードを盗んだだけの第三者を弾ける仕掛けです。

利用者が介在しない連携｜クライアントクレデンシャル

利用者の代理でAPIへアクセスする場合は、認可コードフロー＋PKCEを使います。利用者が介在しないサーバー間処理では、クライアントクレデンシャルを選択してください。夜間バッチで外部サービスへデータを送るようなケースには「許可を出す利用者」が存在しないため、アプリ自身の資格情報で直接トークンを取得します。

入力が難しい機器｜デバイス認可フロー

テレビ、複合機、CLIツールのように文字入力が難しい機器で使う方式。機器の画面にコードを表示し、利用者は手元のスマホやパソコンで認可を済ませます。

現在使うべきでないフロー｜インプリシットとROPC

ROPCは「リソースオーナーパスワードクレデンシャル」の略で、利用者のIDとパスワードをクライアントが直接受け取る方式です。OAuthが解決しようとした問題そのものに逆戻りするため、現在は使用が禁じられています。

フロー	使う場面	2026年8月時点の位置づけ
認可コードフロー＋PKCE	Web・モバイル・SPA	標準。まずこれを選ぶ
クライアントクレデンシャル	サーバー間のAPI連携	現役
デバイス認可フロー	テレビ・複合機など	現役
インプリシット	（旧来の簡易実装）	RFC 9700で「原則として使うべきでない」とされ、OAuth 2.1ドラフトからは削除
ROPC	（旧来の簡易実装）	RFC 9700で「使ってはならない」と明記

※公式ドキュメント（2026年8月時点）に基づきます。

古い解説記事では、インプリシットフローが「代表的なフロー」として今も紹介されている場合があります。設計の参考にする資料は、発行年と準拠している仕様を必ず確認してください。

出典：Proof Key for Code Exchange（RFC 7636）｜RFC Editor／OAuth 2.0 Device Authorization Grant（RFC 8628）｜RFC Editor／Best Current Practice for OAuth 2.0 Security（RFC 9700）｜RFC Editor

OAuth 1.0・2.0・2.1の違いを整理

OAuthは今も更新が続いており、特に2025年以降はセキュリティ要件が大きく整理されました。ここを取り違えると、古い前提のまま設計してしまいます。

OAuth 1.0と2.0の違い

比較項目	OAuth 1.0	OAuth 2.0
通信の保護	リクエストごとに署名を生成	HTTPSによる暗号化を前提とする
実装の負荷	署名処理が複雑で難易度が高い	署名が不要になり簡素化された
対応する用途	Webアプリ中心	モバイル、機器、サーバー間まで拡大

OAuth 2.0は「普及のために簡素化した仕様」と理解すると、後続の動きが読みやすくなります。簡素化で実装の自由度が上がり、その自由度が脆弱な実装を生んだ、という流れがあるためです。

RFC 6749・RFC 9700・OAuth 2.1の関係

文書	位置づけ	2026年8月時点の状態	実務での扱い
RFC 6749	OAuth 2.0の基本仕様	発行済み（2012年10月）	基本的な仕組みを定義
RFC 9700	OAuth 2.0のセキュリティベストプラクティス	発行済み（2025年1月）	新規・既存の実装で優先して従う
OAuth 2.1	OAuth 2.0と後続仕様を統合する次期仕様	IETFドラフト（draft-15）	将来の標準を先取りする設計指針

※公式ドキュメント（2026年8月時点）に基づきます。

OAuth 2.1は、OAuth 2.0とは別の新しい認可方式を作るものではありません。OAuth 2.0の基本仕様と、その後に確立したセキュリティ要件を整理・統合する取り組みです。

OAuth 2.1で整理される主な変更点

ドラフトでは次の6点が整理されています。

認可コードフローを使うすべてのクライアントでPKCEを要求する
リダイレクトURIは完全一致で比較する
インプリシットグラントを仕様から除外する
ROPCを仕様から除外する
ベアラートークンをURLのクエリ文字列に入れる使い方を廃止する
パブリッククライアントのリフレッシュトークンは、送信者制約または使い捨てにする

いずれも「新機能の追加」ではなく、危険な使い方を仕様から消す方向の変更である点が特徴的です。

PKCEはどのクライアントで必須なのか

ここは記事によって説明が食い違いやすい箇所です。正確には次のように整理されます。

RFC 9700ではパブリッククライアントにPKCEを必須とし、コンフィデンシャルクライアントにも利用を推奨しています。OAuth 2.1ドラフトでは、認可コードフローを使うすべてのクライアントにPKCEを要求しています。

パブリッククライアントとは、スマホアプリやSPAのようにクライアントシークレットを安全に保持できないアプリのこと。逆に、サーバー側で秘密情報を守れるアプリがコンフィデンシャルクライアントです。

なお、RFC 9700は認可サーバー側にも「PKCEに対応しなければならない」と定めています。利用する認可サーバーの対応状況は、導入前にご確認ください。

OAuth 2.1は正式リリース済みなのか

OAuth 2.1は、OAuth 2.0と後続のセキュリティ仕様を整理・統合する次期仕様です。2026年8月時点ではIETFのドラフト段階であり、RFCとしては発行されていません。

「OAuth 2.1が正式リリースされた」と書かれた解説を見かけますが、これは誤りです。一方、セキュリティ勧告の実体はRFC 9700としてすでに発行済み。RFC 9700への対応は、OAuth 2.1を見据えた重要な準備になります。

ただし、OAuth 2.1にはRFC 9700以外の後続仕様も取り込まれます。正式発行の際には、差分を改めて確認する必要があるとお考えください。

出典：OAuth 2.1｜OAuth.net／The OAuth 2.1 Authorization Framework｜IETF Datatracker／RFC 9700 Section 2.1.1｜RFC Editor

OAuthとOpenID Connect・SAMLの違い

似た場面で使われる3つの仕様は、担当する役割がはっきり分かれています。OAuthは認可、OpenID ConnectはOAuthを土台にした認証、SAMLは企業向けSSOの認証と覚えてください。

項目	OAuth 2.0	OpenID Connect	SAML
目的	認可（権限の委譲）	認証（本人確認）	認証・SSO
関係	認可の土台	OAuth 2.0の上に構築	OAuthとは独立
主に扱う情報	アクセストークン（形式は実装による）	IDトークン（JWT）	XML形式のSAMLアサーション
主な用途	API連携、データ連携	ソーシャルログイン、モバイルアプリ	社内システムのSSO
向いている場面	このアプリにカレンダーを見せたい	Googleアカウントでログインしたい	社内IdPで全SaaSにSSOしたい

※公式ドキュメント（2026年8月時点）に基づきます。なおOAuth 2.0は、アクセストークンの形式を一律には定めていません。不透明な文字列の場合もあれば、RFC 9068に沿ったJWTの場合もあります。

OAuthとOpenID Connectの違い

OpenID Connect（OIDC）は、OAuth 2.0の上に構築された認証のための仕様です。アクセストークンに加えて、IDトークンという本人を証明する情報を発行します。両者は競合関係ではなく、「土台がOAuth、その上に認証機能を載せたものがOpenID Connect」という積み重ねの関係。「Googleでログイン」の多くは、内部的にOIDCで動いています。

OAuthとSAMLの違い

SAMLは、OAuthとは独立して発展してきた認証・SSOの仕様です。XML形式でやり取りする点が特徴で、企業のIdP（社内の認証基盤）から複数のSaaSへシングルサインオンする用途で広く使われています。

ログイン・API連携・社内SSOでの使い分け

ログインさせたい → OpenID Connect
データや機能を触らせたい → OAuth
社内の全SaaSにSSOしたい → SAMLまたはOpenID Connect

サービスを選定する際は、「OAuth対応」とだけ書かれた製品資料を鵜呑みにせず、ログイン連携なのかAPI連携なのかを確認しましょう。同じ「対応」でも意味が異なります。

出典：OpenID Connect Core 1.0｜OpenID Foundation／JWT Profile for OAuth 2.0 Access Tokens（RFC 9068）｜RFC Editor

OAuthのメリットとデメリット

OAuthが広く普及したのは、利用者と提供者の双方に利点があるためです。ただし万能ではありません。

メリット｜パスワードを渡さず、権限を絞り、個別に解除できる

パスワードを連携先へ渡さずに済む：連携先が漏えいしても、本体アカウントのパスワードは無事
スコープで権限を限定できる：「閲覧のみ」といった粒度で絞れるため、影響範囲を抑えられる
アプリ単位で連携を解除できる：パスワード変更でほかの連携まで巻き添えにする事態を避けられる

デメリット｜実装難易度と、同意画面の読み飛ばし

実装の難易度が高い：仕様の選択肢が多く、誤った組み合わせを選ぶと脆弱になる
外部アカウントや認可サーバーへの依存：ソーシャルログインでは連携元アカウントが停止するとログインできなくなる場合がある。API連携でも、認可サーバーの障害やトークン失効で機能が止まる可能性がある
利用者が同意画面を読まない：内容を確認せず「許可」を押すと、想定外の権限まで渡ってしまう

3つ目はOAuthそのものの欠陥ではなく、運用上の弱点です。そして、この弱点を狙う攻撃が実際に発生しています。

OAuthの危険性｜実際に起きる5つのリスク

OAuthの主なリスクは、悪意あるアプリへの同意、トークンの盗難、リダイレクトURIの検証不備、過剰な権限付与、そして古いフローの継続利用です。

リスク1｜同意フィッシング（Consent Phishing）

同意フィッシングは、企業が特に注意したい代表的なOAuth悪用手口です。攻撃者が正規の認可サーバーに悪意あるアプリを登録し、利用者を同意画面へ誘導して権限を承認させます。厄介なのは、画面そのものは本物だという点。URLもドメインも正規のもので、偽サイトを見破る従来の勘が通用しません。

同意フィッシングはパスワードではなく、利用者による権限付与を狙います。そのため、MFAだけでは防げず、同意ポリシーやアプリ監査が必要です。

実例もあります。Microsoftは、2022年12月に始まった同意フィッシングキャンペーンを確認しました。攻撃者は正規企業になりすまし、悪意あるOAuthアプリに「検証済み発行元」の表示を付けていたとのことです。

リスク2｜アクセストークンの盗難

アクセストークンを盗まれると、攻撃者がトークンの有効期限・スコープ・対象リソースの範囲内でAPIへ不正アクセスするおそれがあります。主な原因は、HTTPS未使用の通信、ログファイルへのトークン出力、クライアント側での不適切な保存です。

リスク3｜リダイレクトURIの検証不備

認可サーバーが戻り先URLを厳密に確認していないと、攻撃者のサイトへ誘導され、認可コードやトークンを奪われます。前方一致や部分一致で検証していると、攻撃者のサブドメインやパスを通してしまうため危険です。

リスク4｜過剰なスコープ要求

「予定の閲覧」だけで足りるツールが「メールの全件読み取り」まで要求している、といったケースです。利用者が同意画面を読み飛ばせば、この過剰要求はそのまま通ってしまいます。

リスク5｜古いフローの継続利用

インプリシットフローのように、現在は使うべきでないとされた方式を使い続けている実装です。過去に構築したシステムを見直さないまま運用していると、この状態に陥りやすくなります。

一般利用者がOAuth連携を確認・解除する方法

不審な連携がないか確認するには、GoogleアカウントやMicrosoftアカウントのセキュリティ設定から、アクセス権を付与したアプリを一覧表示します。使っていないアプリや、用途に対して権限が大きすぎるアプリは連携を解除してください。

なお、パスワードを変更しただけでは、発行済みのトークンや連携権限が必ず解除されるとは限りません。各サービスの連携アプリ管理画面から明示的に取り消すことが重要です。

出典：同意フィッシングから保護する｜Microsoft Learn／検証済みの発行者確認を悪用する脅威アクターの同意フィッシングキャンペーンについて｜Microsoft Security Response Center／サードパーティとの接続を管理する｜Google アカウントヘルプ

OAuthを安全に実装するための対策

自社サービスにOAuthを組み込む場合、拠り所になるのは2025年1月に発行されたRFC 9700です。これが現時点の公式なセキュリティBCP（ベストプラクティス）にあたります。

RFC 9700に沿った6つの対策

#	対策	ポイント
1	認可コードフロー＋PKCEを使う	パブリッククライアントは必須、コンフィデンシャルクライアントも推奨
2	リダイレクトURIは完全一致で検証	事前登録したURIと単純な文字列一致で比較。ネイティブアプリのlocalhostにおけるポート番号のみ例外
3	古いフローを避ける	インプリシットは原則として使用せず、ROPCは使用しない
4	通信をHTTPSで保護する	認可コードやトークンの盗聴を防ぐ
5	トークンの有効期限を短くし、失効の仕組みを持つ	パブリッククライアントのリフレッシュトークンは送信者制約またはローテーション
6	トークンの受け取り手を検証する	自分宛でないトークンは受け付けない

※公式ドキュメント（2026年8月時点）に基づきます。

2番を補足します。リダイレクトURIは、事前登録したURIと単純な文字列一致で比較してください。例外はネイティブアプリがlocalhostへリダイレクトする場合のポート番号だけで、パスやドメインの前方一致・部分一致は認められません。

トークンの保管・失効・ローテーション

アクセストークンは有効期限を短く設定します。特にパブリッククライアントへリフレッシュトークンを発行する場合は、送信者制約またはローテーションのいずれかで保護しなければなりません。ローテーションとは、トークンを使うたびに新しいものへ更新し、古いトークンの再利用を検知する方式です。

送信者制約には、mTLSやDPoPといった仕組みがあります。これらを使えば、トークンを持っているだけでは使えない状態にできます。

認可サーバー・IDaaSを選ぶ4つの基準

OAuthの認可処理をゼロから独自実装するのは避け、実績あるライブラリ、認可サーバー製品、IDaaSのいずれかを利用するのが基本です。RFC 9700が扱う攻撃手法は多岐にわたり、そのすべてに自前で対処するのは現実的ではありません。

製品を選ぶ際は、次の4点で比較すると判断しやすくなります。

既存環境との親和性：すでに使っているクラウドやSaaSと統合しやすいか
想定ユーザー数と課金体系：利用者数の増加に対して費用がどう変化するか
運用できる人材がいるか：構築後の保守を誰が担うのか
準拠すべき規格：OpenID ConnectやSAMLへの対応が必要か

選択肢は性質によって3つに分かれます。クラウド事業者のID基盤は既存のMicrosoft 365やGoogle Workspaceと統合しやすく、専業IDaaSは導入が速く連携先が豊富。OSSは自由度が高い一方、構築・運用の工数を自社で負担します。ライセンス費用がゼロでも総保有コストが安いとは限らないため、運用工数まで含めて比較してください。

出典：Best Current Practice for OAuth 2.0 Security（RFC 9700）｜RFC Editor／Microsoft ID プラットフォームの認証プロトコル｜Microsoft Learn

情シス・DX担当者向け｜OAuthアプリを管理する4ステップ

OAuthのリスク対策は、開発者だけの話ではありません。すでにSaaSを導入している企業では、管理者側で「誰がどのアプリに何を許可したか」を可視化し、制御する必要があります。

ステップ1｜連携済みアプリとスコープを棚卸しする

出発点は現状把握です。Microsoft Entra IDやGoogle Workspaceの管理コンソールから、テナント内で使われているアプリと付与済みのスコープを一覧化します。Google Workspaceでは、管理者がアプリ単位・ユーザー単位で、利用者が同意する3者間OAuth（3-legged OAuth）のトークンを確認し、失効させることが可能です。

一覧化すると、管理部門が把握していなかった外部アプリや、想定以上のユーザーが利用しているアプリが見つかる可能性があります。

ステップ2｜利用者の同意ポリシーを設定する

次に、従業員が自由にアプリへ同意できる状態を見直します。管理者承認フローに切り替えれば、新しいアプリへの権限付与を事前にチェックできるでしょう。Google Workspaceでは、2024年12月からOAuth 2.0スコープ単位でのアクセス制御が一般提供されました。

ステップ3｜不要・不審なアプリのトークンを失効させる

棚卸しの結果をもとに、次の条件に当てはまるアプリを整理します。

発行元が不明、または実在が確認できない
用途に対して要求スコープが明らかに過剰
一定期間まったく利用実績がない

あわせて、従業員には「同意画面のアプリ名と要求権限を必ず読む」よう周知してください。ただし周知だけでは十分ではありません。ステップ2の同意ポリシー、管理者承認、次のステップで扱うアプリ監査と組み合わせて対策します。

ステップ4｜監査ログで新規の権限付与を検知する

最後は継続的な監視です。新規のOAuth権限付与レポートを定期的に確認し、短時間での大量付与や見慣れないアプリ名を検知できる体制を整えます。月次レビューを運用に組み込んでおくと、異常の早期発見につながるでしょう。

なお、AIアシスタントやエージェントがOAuthを使って社内SaaSへ接続する場合も、アクセストークンが発行されます。AIツールに付与したトークンも、人が使うアプリと同じ管理対象として扱ってください。

Microsoft 365の基本認証廃止とOAuth移行

実務で今まさに動いているのが、Exchange Onlineの基本認証廃止です。

EWS・POP・IMAP・Exchange ActiveSync・リモートPowerShellなどでは、基本認証がすでに無効化されています。継続利用する場合は、OAuth 2.0に対応した認証方式や、Microsoftが推奨する後継手段への移行が必要です。

SMTP AUTHは例外として現在も基本認証を利用できますが、段階的な廃止が予定されています。2026年8月時点の予定は次のとおりです。

2026年12月末まで：現在の動作を維持
2026年12月末：既存テナントでは基本認証を既定で無効化。ただし管理者による再有効化は可能
2026年12月より後に作成される新規テナント：基本認証は既定で利用不可
2027年後半：Microsoftが最終的な完全廃止日を発表予定

複合機のスキャン送信や、業務システムの自動通知メールは早めに棚卸ししてください。SMTP AUTHのOAuth対応、Microsoft Graph API、SMTPリレーなど、利用条件に合う移行先を検討します。廃止スケジュールは変更される可能性があるため、移行計画を立てる際は公式ブログで最新情報をご確認ください。

出典：Google Workspace のデータにアクセスできるアプリを制御する｜Google Workspace 管理者ヘルプ／Exchange Online での基本認証の廃止｜Microsoft Learn／Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline｜Microsoft Community Hub

AIエージェント時代のOAuth｜MCPで認可が重要になる理由

生成AIとツールをつなぐ標準仕様が、MCP（Model Context Protocol）です。リモートのMCPサーバーへHTTPで接続し、利用者の権限を扱う場面では、OAuthが重要な役割を担います。HTTPベースのMCPで認可を実装する場合、2026年7月28日版の仕様はOAuth 2.1を土台とした認可方式を定めています。

すべてのMCP接続でOAuthが必要なわけではない

MCPの認可機能は任意です。2026年7月28日版仕様では、HTTPベースのMCPで認可を実装する場合に、OAuth 2.1を土台とした認可仕様への準拠が推奨されます。一方、同じ端末内でプロセス間通信を行うSTDIO接続は、このOAuth認可フローの対象外。実行環境から認証情報を受け取る設計が推奨されています。

つまり、手元のパソコンで動かすローカルのMCPサーバーと、社外からアクセスするリモートのMCPサーバーでは、考えるべきことが変わります。

なお、MCP 2026-07-28仕様が参照するOAuth 2.1はdraft-13です。IETF上のOAuth 2.1最新草案はdraft-15ですが、MCPを実装する際はMCP仕様が定める要件を優先して確認してください。

MCPクライアント・MCPサーバー・認可サーバーの関係

MCPサーバー：OAuth 2.1のリソースサーバーとして振る舞う
MCPクライアント：OAuth 2.1のクライアントとして振る舞う
認可サーバー：利用者とやり取りし、アクセストークンを発行する

MCPサーバーは、対応する認可サーバーの場所をクライアントへ示します。そのために、OAuth 2.0 Protected Resource Metadata（RFC 9728）の実装が必要です。

PKCEとリソースインジケーター、トークンパススルーの禁止

セキュリティ面の要件は3つ。ひとつはPKCEの実装で、MCPクライアントは認可コードの横取りを防ぐためにこれを実装します。

ふたつめがリソースインジケーター（RFC 8707）。「このトークンはどのMCPサーバー向けか」を明示する仕組みで、MCPクライアントには必須とされました。受け取る側のMCPサーバーも、自分宛でないトークンは受け付けてはならないと定められています。

みっつめがトークンパススルーの禁止です。受け取ったトークンをそのまま外部APIへ横流しすると、下流のAPIが「検証済みのトークンだ」と誤認しかねません。外部APIを呼ぶ場合は、そのAPI向けに別途発行されたトークンを使います。

2026年7月28日版で強化された点

最新版では、認可まわりに次の変更が加えられました。

認可サーバーは認可レスポンスにissパラメータを含めることが推奨され、クライアントは認可コードを引き換える前にissuerを検証します（RFC 9207）。認可サーバーの取り違えを防ぐ措置です
クライアント資格情報は、それを発行した認可サーバーのissuerに束縛。別の認可サーバーへ同じ資格情報を再利用してはならず、誤送信を防ぎます
動的クライアント登録（DCR）は非推奨となり、クライアントIDメタデータドキュメント（CIMD）が推奨されました。DCRは後方互換性のために利用できるものの、将来のMCP仕様では削除される予定です

ここで登場する2つの用語も押さえておきましょう。

issuer（発行元識別子）：どの認可サーバーが認可レスポンスや資格情報を発行したかを示す値
audience（トークンの宛先）：そのアクセストークンをどのMCPサーバーで使えるかを示す値

MCPは更新頻度が高い仕様です。実装や製品選定の判断に使う際は、公式サイトで現行版をご確認ください。要点を表にまとめます。

確認項目	MCP 2026-07-28仕様の要点
認可の必須性	任意
HTTP接続	認可を実装する場合は仕様準拠を推奨
STDIO接続	OAuth認可フローを使わず、実行環境から認証情報を取得
トークンの宛先	resourceパラメータとaudienceを検証
クライアント登録	CIMDを推奨、DCRは非推奨
発行元検証	issを検証して認可サーバーの取り違えを防止