OAuth 2.0 と OIDC (OpenID Connect) は、Microsoft Entra ID の認証・認可基盤を支える 2 つの標準プロトコルです。 現代の Web アプリ・モバイルアプリ・バックエンドサービスのすべてがこれらのフローを使って Azure 認証を実現します。 本記事では、Microsoft Entra ID で使用される全フロー・選定基準・実装パターンを網羅的に整理します。
| 項目 | OAuth 2.0 | OIDC |
|---|---|---|
| 役割 | 認可 (Authorization) | 認証 (Authentication) |
| 発行 Token | Access Token | ID Token (+ Access Token) |
| 用途 | リソースへのアクセス権 | ユーザー識別情報 |
| Token 形式 | JWT または Opaque | JWT (JSON Web Token) |
| クレーム | scope・aud | sub・email・name・groups |
Microsoft Entra ID では両方をサポートし、Microsoft 365 / Azure サービスへのアクセスは OAuth 2.0 + OIDC を組み合わせて実現。 アプリ実装では『ユーザーログイン (OIDC)』+『API アクセス (OAuth 2.0)』を一連のフローで処理するのが標準です。
現代の Web アプリ・モバイルアプリの標準認証フロー。
PKCE (Proof Key for Code Exchange) は SPA や Mobile App のように Client Secret を保管できないクライアントでのコード横取り攻撃を防ぐ仕組み。 新規 Web アプリは全クライアントタイプで Authorization Code + PKCE 推奨です。
Implicit Flow は廃止予定 (Deprecated)、新規実装で使うべきではない。
代替: SPA も Authorization Code + PKCE Flow を使うのが現在の標準 (Microsoft Authentication Library MSAL.js 2.x で標準対応)。 既存 Implicit Flow アプリは段階的に Authorization Code + PKCE へ移行が推奨。
ユーザー操作なしのバックエンドサービス (Daemon・CronJob・Worker Process) が Microsoft Graph や Azure API にアクセスするフロー。
Workload Identity Federation 適用で Secret 不要化が現代のベストプラクティス。詳細は Managed Identity vs Service Principal 参照。
ユーザーが認証済みのアプリ (Frontend) が、ユーザーの権限を持ったまま別の API (Backend / Microsoft Graph) を呼び出すフロー。
ユーザー → Frontend Web App (Entra ID 認証) → Frontend が Backend API を呼び出し → Backend が Microsoft Graph をユーザーの名前で呼び出し。
これにより多段 API でユーザー権限が継承され、Backend が独自に Service Principal 権限を持つ必要がなくなります。
ユーザー操作可能なブラウザを持たないデバイス (IoT デバイス・CLI ツール・スマート TV) でユーザー認証する仕組み。
| 項目 | Delegated | Application |
|---|---|---|
| 動作 | ユーザーの権限を借りて API 呼び出し | アプリ自体の権限で API 呼び出し |
| Token | User Token | Application Token (Client Credentials) |
| 範囲 | ユーザーが持つ権限の範囲内 | Tenant 全体に対する高権限 |
| 例 | User.Read (自分の情報) | User.Read.All (全ユーザー情報) |
| Admin Consent | 個別ユーザー同意可 | 必須 (Global Administrator) |
| 用途 | ユーザー操作のあるアプリ | バックエンドサービス |
設計原則: ユーザー操作のあるアプリは Delegated 一択、バックエンドサービスは Application + Workload Identity Federation の組み合わせ。
MSAL は Microsoft が提供する OAuth 2.0 / OIDC フローを抽象化したクライアントライブラリ。複数言語サポート:
新規実装では MSAL を直接使うのが標準、ADAL (Active Directory Authentication Library) はレガシーで非推奨。MSAL は Token キャッシュ・Refresh Token 自動更新・Conditional Access 統合などを自動処理します。
OAuth 2.0 と OIDC の違いは?
OAuth 2.0 は『認可 (Authorization)』のプロトコル、リソースへのアクセス権 (Access Token) を発行する仕組み。OIDC (OpenID Connect) は OAuth 2.0 を拡張した『認証 (Authentication)』のプロトコル、ユーザー識別情報 (ID Token) を提供。ID Token は JWT (JSON Web Token) 形式で、ユーザーの ID・Email・名前・グループメンバーシップ などのクレームを含む。Microsoft Entra ID では両方をサポートし、Microsoft 365 / Azure サービスへのアクセスは OAuth 2.0 + OIDC を組み合わせて実現。アプリ実装では『ユーザーログイン (OIDC)』+『API アクセス (OAuth 2.0)』を一連のフローで処理するのが標準パターンです。
Authorization Code Flow + PKCE とは?
Authorization Code Flow + PKCE は、現代の Web アプリ・モバイルアプリの標準認証フロー。フロー: 1) アプリが Code Verifier (ランダム文字列) を生成し SHA-256 ハッシュした Code Challenge を Authorize エンドポイントに送信、2) ユーザーが Microsoft Entra ID でログイン → 同意、3) Entra ID が Authorization Code をアプリにリダイレクト、4) アプリが Code + 元の Code Verifier を Token エンドポイントに送信、5) Entra ID が Code と PKCE Challenge を検証し ID Token + Access Token + Refresh Token を返却。PKCE (Proof Key for Code Exchange) は SPA (Single Page Application) や Mobile App のように Client Secret を保管できないクライアントでのコード横取り攻撃を防ぐ仕組み。新規 Web アプリは全クライアントタイプで Authorization Code + PKCE 推奨です。
Implicit Flow は今でも使えますか?
Implicit Flow は廃止予定 (Deprecated)、新規実装で使うべきではない。Implicit Flow は SPA (Single Page Application) 向けに設計されたフローで、Token エンドポイントを経由せず Authorize エンドポイントから直接 Access Token をフラグメント形式 (#access_token=...) で返す。問題点: 1) Access Token がブラウザ履歴に残る、2) Refresh Token を発行できない、3) コード横取り攻撃 (CSRF Token Replay) に弱い。代替: SPA も Authorization Code + PKCE Flow を使うのが現在の標準 (Microsoft Authentication Library MSAL.js 2.x で標準対応)。既存 Implicit Flow アプリは段階的に Authorization Code + PKCE へ移行が推奨で、Microsoft Identity Platform は Implicit Flow のサポートを継続するが新規実装は禁止扱いです。
Client Credentials Flow とは?
Client Credentials Flow は、ユーザー操作なしのバックエンドサービス (Daemon・CronJob・Worker Process) が Microsoft Graph や Azure API にアクセスするフロー。Service Principal の Client ID + Client Secret (または Certificate・Workload Identity Federation) を Token エンドポイントに送信して Access Token を取得。User Token (ユーザー権限) ではなく Application Token (アプリ権限) を発行、API Permissions の Application 種別が必要 (例: User.Read.All for Microsoft Graph)。代表的なユースケース: 1) スケジュールバックアップアプリ、2) 全 Tenant ユーザーリスト取得バッチ、3) DevOps パイプラインの Azure リソース操作、4) Webhook 受信アプリ。Workload Identity Federation 適用で Secret 不要化が現代のベストプラクティスです。
On-Behalf-Of Flow とは?
On-Behalf-Of (OBO) Flow は、ユーザーが認証済みのアプリ (Frontend) が、ユーザーの権限を持ったまま別の API (Backend / Microsoft Graph) を呼び出すフロー。代表シナリオ: ユーザー → Frontend Web App (Entra ID 認証) → Frontend が Backend API を呼び出し → Backend が Microsoft Graph をユーザーの名前で呼び出し。フロー: 1) Frontend がユーザーから Authorization Code Flow で User Token A 取得、2) Frontend が Backend API を Token A で呼び出し、3) Backend が Token A を Token エンドポイントに送信し『User Token A の権限で Microsoft Graph 用の Token B が欲しい』とリクエスト、4) Entra ID が Token B 発行、5) Backend が Microsoft Graph を Token B で呼び出し。これにより多段 API でユーザー権限が継承され、Backend が独自に Service Principal 権限を持つ必要がなくなります。
Device Code Flow はいつ使いますか?
Device Code Flow は、ユーザー操作可能なブラウザを持たないデバイス (IoT デバイス・CLI ツール・スマート TV) でユーザー認証する仕組み。フロー: 1) Device が Code を取得 (例: ABCD-EFGH)、2) Device がユーザーに『https://microsoft.com/devicelogin にアクセスして ABCD-EFGH を入力してください』と表示、3) ユーザーが別の PC/スマホからブラウザでアクセス → Entra ID ログイン → Code 入力 → 同意、4) Device が Polling で Token エンドポイントに問い合わせ、5) ユーザー認証完了後に Token 取得。代表的なユースケース: Azure CLI の az login (デバイスコードオプション)・Visual Studio Code の Azure Account 拡張機能・Azure PowerShell・組み込みデバイスの初回セットアップ。CLI ツールやヘッドレス環境で広く使われる重要なフローです。
API Permissions の Delegated と Application の違いは?
Delegated Permissions: ユーザーの権限を借りて API を呼び出す、User Token ベース、ユーザーが持つ権限の範囲内でアクセス。Application Permissions: アプリ自体の権限で API を呼び出す、Application Token ベース (Client Credentials Flow)、Tenant 全体に対する高い権限を持てる。例: Microsoft Graph の User.Read (Delegated) はサインインユーザーの自分の情報のみ取得可、User.Read.All (Application) は全 Tenant ユーザー情報取得可。Application Permissions は Admin Consent (Global Administrator の承認) が必須で、付与時の慎重さが必要。設計原則: ユーザー操作のあるアプリは Delegated 一択、バックエンドサービスは Application + Workload Identity Federation の組み合わせ、というのが現代的なベストプラクティスです。
関連認定試験は?
SC-300 (Identity and Access Administrator Associate) のドメイン 3 (アプリへのアクセス管理 25-30%) で OAuth 2.0 / OIDC フローが深く問われる本領域の本命認定。AZ-204 (Developer Associate、2026-07 リタイア注意) のドメイン 3 (Security 20-25%) で MSAL ライブラリでの実装、AI-103 (2026-06 GA) で Azure OpenAI / AI Search への認証パターン、SC-100 (Cybersecurity Architect Expert) でゼロトラスト認証アーキテクチャ、MS-102 (Microsoft 365 Administrator Expert) のドメイン 2。Azure / Microsoft 365 アプリケーション開発者・ID 管理者にとって OAuth 2.0 / OIDC の理解は必須スキルです。
関連記事・技術深掘り
SC-300 完全ガイド｜Microsoft Identity and Access Administrator Associate 出題範囲・学習リソース・合格戦略【2026 年版】
Microsoft Certified: Identity and Access Administrator Associate (SC-300) の完全ガイド。4 ドメインの出題範囲、Microsoft Entra ID の ユーザー / グループ / アプリ管理、Conditional Access / MFA / PIM / Entra ID Governance の実装、3-4 ヶ月の合格ロードマップ、SC-200 / SC-100 / SC-500 への展開ルートを日本語で網羅。
Azure セキュリティエンジニア キャリアロードマップ｜SC-900 → SC-200/300/400 → SC-100 シニアへの道【2026 年版】
Azure セキュリティエンジニアになるための認定取得ロードマップ完全版。SC-900 → SC-200/300/400 のいずれか → SC-100 / SC-500 の王道ルート、ロール別の優先順序、CISSP との二刀流戦略、SC-500 (旧 AZ-500 後継、2026-09 GA 予定) の動向、10-15 ヶ月の学習プラン、年収レンジまで日本語で網羅。
AZ-104 vs AZ-204 完全比較｜Microsoft Azure Administrator vs Developer Associate の違いと選び方【2026 年版】
Microsoft Azure の 2 大 Associate 認定 AZ-104 (Administrator) と AZ-204 (Developer) を完全比較。対象ロール・出題範囲・難易度・学習時間・受験料・キャリアパスを表形式で整理。AZ-204 2026 年 7 月リタイア後の判断材料、両方取る価値、次の認定への進路まで日本語で網羅。
Microsoft Entra ID パスワードレス認証完全ガイド｜Authenticator・FIDO2・Windows Hello・TAP・CBA【2026 年版】
Microsoft Entra ID のパスワードレス認証 5 方式 (Microsoft Authenticator・FIDO2・Windows Hello for Business・Temporary Access Pass・Certificate-based) を完全解説。Number Matching・段階的導入ロードマップ・特権ロール向け FIDO2・関連認定試験 (SC-300 / SC-100 / MS-102) を日本語で網羅。
本記事の技術情報は Microsoft Identity Platform Documentation およびMSAL Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure、Microsoft Entra は Microsoft group of companies の商標です。OAuth 2.0 は IETF・OIDC は OpenID Foundation の規格です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。
NicheeLab編集部
データエンジニアリング・クラウド資格の専門家。Databricks・Snowflake等の認定資格を保有し、実務経験に基づいた問題作成・解説を行っています。NicheeLab運営。
AZ-900 完全ガイド｜Microsoft Azure Fundamentals 出題範囲・学習リソース・合格戦略
Microsoft Azure Fundamentals (AZ-900) の 2026 年 1 月 14 日改訂版に対...
Azure 認定資格ロードマップ 2026 完全版｜全 26 試験の体系と大型再編 (AI-901/AI-103/SC-500)
Microsoft Azure 認定資格 全 26 試験 (現行 23 + 退役 3) の 2026 年版ロードマップ。...
AI-901 完全ガイド｜Azure AI Fundamentals 新試験
Microsoft Certified: Azure AI Fundamentals (AI-901) の出題範囲・Mi...
Microsoft Entra ID 入門｜旧 Azure AD から学ぶ ID 管理 (AZ-900/SC-900/AZ-104 必須知識)
Microsoft Entra ID (旧 Azure Active Directory) の入門解説。2023 年 7...
DP-900 完全ガイド｜Azure Data Fundamentals 出題範囲・学習リソース・合格戦略
Microsoft Azure Data Fundamentals (DP-900) の完全ガイド。4 ドメインの出題範...