OIDC認証とSAML認証の違いを徹底比較：仕組み・ユースケース・選び方まで解説

公開日: 2026-04-07 4分 / 697文字 セキュリティ認証OIDCSAMLAzureEntra IDSSOアイデンティティ

はじめに

企業のシングルサインオン（SSO）を設定する際に必ず登場する「OIDC」と「SAML」。どちらも認証・認可のためのプロトコルですが、設計思想・動作フロー・ユースケースが大きく異なります。

本記事では、両プロトコルの仕組みをゼロから解説し、実際の導入判断に役立つ比較を行います。

この記事で分かること

  • SAMLとOIDCそれぞれの仕組みと認証フロー
  • トークン形式・通信方式の違い
  • ユースケース別の使い分け方針
  • Azure Entra ID（旧Azure AD）での具体的な活用場面
  • マイクロサービスやモバイルアプリへの適合性

1. 認証・認可の基礎知識

1.1 認証（Authentication）と認可（Authorization）の違い

概念英語意味例
認証Authentication (AuthN)「あなたは誰か」を確認するIDとパスワードでログイン
認可Authorization (AuthZ)「何ができるか」を制御する管理者のみがファイル削除可能

OIDCは認証+認可を扱うプロトコルで、SAMLは主に認証情報の伝達に特化しています。

1.2 SSOとIdP・SPの関係

シングルサインオン（SSO）の世界では、以下の登場人物が重要です。

役割名称説明
IdPIdentity Provider（アイデンティティプロバイダー）認証を担当するサーバー（例：Azure Entra ID、Okta）
SP/RPService Provider / Relying Party（サービスプロバイダー）アプリ側（例：Salesforce、GitHub）
ユーザーUser / Subject実際にログインする人
ユーザー ←→ IdP（認証）←→ SP/アプリ（リソース提供）

2. SAML（Security Assertion Markup Language）

2.1 SAMLとは

SAMLは2002年にOASIS（標準化団体）が策定したXMLベースの認証・認可フレームワークです。SAMLの最新版はSAML 2.0（2005年策定）で、現在も多くのエンタープライズシステムで使用されています。

特徴

  • XMLを使った**アサーション（Assertion）**でユーザー情報を伝達
  • ブラウザのリダイレクト・POSTを使った通信
  • エンタープライズ向けに設計された堅牢な仕様
  • デジタル署名による改ざん防止

2.2 SAMLの認証フロー（SP-Initiated）

最も一般的なSP-Initiated（サービスプロバイダー起点）フローを示します。

sequenceDiagram actor User as ユーザー participant SP as SP
（アプリ） participant IdP as IdP
（Azure Entra ID等） User->>SP: ①保護されたリソースにアクセス SP->>User: ②SAMLリクエスト生成
IdPへリダイレクト User->>IdP: ③SAMLリクエスト送信
（URLパラメータ） IdP->>User: ④ログイン画面表示
（未認証の場合） User->>IdP: ⑤認証情報入力 IdP->>User: ⑥SAMLレスポンス（XML）
ブラウザ経由でPOST User->>SP: ⑦SAMLアサーション送信 SP->>SP: ⑧署名検証・ユーザー情報抽出 SP->>User: ⑨リソース提供・ログイン完了

2.3 SAMLアサーションの構造

SAMLはXML形式でユーザー情報（アサーション）を伝達します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_abc123" Version="2.0"
    IssueInstant="2026-04-07T10:00:00Z">

  <!-- 発行者（IdP）の情報 -->
  <saml:Issuer>https://login.microsoftonline.com/tenant-id/saml2</saml:Issuer>

  <!-- デジタル署名 -->
  <ds:Signature>...</ds:Signature>

  <!-- 認証対象ユーザーの識別子 -->
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      [email protected]
    </saml:NameID>
  </saml:Subject>

  <!-- 有効期限 -->
  <saml:Conditions NotBefore="2026-04-07T09:59:00Z"
                   NotOnOrAfter="2026-04-07T11:00:00Z"/>

  <!-- 属性（ユーザー情報） -->
  <saml:AttributeStatement>
    <saml:Attribute Name="displayName">
      <saml:AttributeValue>山田 太郎</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="groups">
      <saml:AttributeValue>IT管理者</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>

</saml:Assertion>

SAMLのアサーション種別

種別用途
Authentication Assertion認証が成功したことの証明
Attribute Assertionユーザーの属性情報（氏名・グループ等）
Authorization Decision Assertionリソースへのアクセス可否

3. OIDC（OpenID Connect）

3.1 OIDCとは

OIDCは2014年にOpenID Foundationが策定したOAuth 2.0をベースにした認証レイヤーです。OAuth 2.0が「認可」のみを扱うのに対し、OIDCはその上に「認証」機能を追加しました。

特徴

  • JSON/JWTベースのシンプルな設計
  • RESTful APIとの高い親和性
  • モバイルアプリ・SPAに適した設計
  • アクセストークン・IDトークン・リフレッシュトークンの3種類を使い分ける

3.2 OIDCの認証フロー（Authorization Code Flow）

最も安全なAuthorization Code Flowを示します。

sequenceDiagram actor User as ユーザー participant App as クライアントアプリ participant IdP as IdP
（認可サーバー） participant API as リソースサーバー
（API） User->>App: ①ログインボタンをクリック App->>User: ②認可エンドポイントへリダイレクト
（client_id, scope, state, nonce含む） User->>IdP: ③認証・同意画面 User->>IdP: ④認証情報入力・同意 IdP->>App: ⑤認可コード返却
（コールバックURL経由） App->>IdP: ⑥認可コード + client_secret でトークン要求 IdP->>App: ⑦IDトークン・アクセストークン・
リフレッシュトークン返却 App->>App: ⑧IDトークン検証（JWT署名確認） App->>API: ⑨アクセストークンを付与してAPIコール API->>App: ⑩レスポンス App->>User: ⑪ログイン完了・コンテンツ表示

3.3 OIDCのトークン

OIDCでは3種類のトークンが発行されます。

IDトークン（認証の証明）

JWTフォーマットで、ユーザーが誰かを証明します。

# ヘッダー（Base64URLデコード）
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "鍵識別子"
}

# ペイロード（Base64URLデコード）
{
  "iss": "https://login.microsoftonline.com/tenant-id/v2.0",
  "sub": "ユーザーの一意識別子",
  "aud": "client-id-of-your-app",
  "exp": 1744027200,
  "iat": 1744023600,
  "nonce": "ランダム値（リプレイ攻撃防止）",
  "name": "山田 太郎",
  "email": "[email protected]",
  "groups": ["IT管理者", "一般ユーザー"]
}

# 署名（IdPの秘密鍵で署名）

アクセストークン（APIアクセス用）

リソースサーバー（API）へのアクセス権を示すトークン。JWTまたは不透明なランダム文字列の場合があります。

リフレッシュトークン（長期セッション用）

アクセストークンの有効期限が切れた後、再ログインなしで新しいトークンを取得するために使います。

4. SAML vs OIDC 徹底比較

4.1 基本仕様の比較

項目SAML 2.0OIDC
策定年2005年2014年
策定団体OASISOpenID Foundation
ベースプロトコルSOAP/HTTPOAuth 2.0
データ形式XMLJSON / JWT
通信方式ブラウザリダイレクト + POSTREST API
主な用途認証情報の伝達認証 + 認可
設定の複雑さ高（XMLメタデータ交換が必要）低（ディスカバリーエンドポイントで自動）

4.2 対応環境・ユースケースの比較

ユースケースSAMLOIDC推奨
エンタープライズ向けWebアプリ◎○SAML
既存のオンプレシステム連携◎△SAML
モバイルアプリ（iOS/Android）×◎OIDC
SPA（シングルページアプリ）×◎OIDC
マイクロサービス・API間認証×◎OIDC
クラウドネイティブ新規開発△◎OIDC
Salesforce・ServiceNow等のSaaS◎○両対応（製品依存）
Google Workspace SSO◎○SAML
GitHub Enterprise SSO◎◎両対応

4.3 セキュリティ特性の比較

graph LR subgraph SAML["SAMLのセキュリティ"] S1[XMLデジタル署名] S2[XML暗号化] S3[リプレイ攻撃防止
AssertionID管理] S4[有効期限
Conditions要素] end subgraph OIDC_S["OIDCのセキュリティ"] O1[JWT署名
RS256/ES256] O2[state パラメータ
CSRF防止] O3[nonce
リプレイ攻撃防止] O4[PKCE
コード横取り防止] O5[トークン有効期限
exp クレーム] end
セキュリティ要素SAMLOIDC
署名アルゴリズムRSA-SHA256（XML DSig）RS256 / ES256（JWT）
暗号化XML EncryptionTLSに依存（トークン自体は原則平文）
CSRF対策RelayState パラメータstate パラメータ
リプレイ攻撃対策AssertionID の一意性nonce クレーム
PKCE対応なしあり（SPAやモバイルで必須）
トークン失効アサーション有効期限トークン失効エンドポイント

5. Azure Entra IDでの活用場面

5.1 Entra IDがサポートするプロトコル

Azure Entra ID（旧Azure AD）はSAML 2.0とOIDCの両方をサポートしています。アプリ登録時にどちらを使うか選択できます。

graph TD EntraID["Azure Entra ID
（IdP）"] EntraID -->|SAML 2.0| S1["Salesforce"] EntraID -->|SAML 2.0| S2["Google Workspace"] EntraID -->|SAML 2.0| S3["ServiceNow"] EntraID -->|SAML 2.0| S4["オンプレ SAMLアプリ"] EntraID -->|OIDC / OAuth 2.0| O1["Microsoft 365
（Teams, SharePoint）"] EntraID -->|OIDC / OAuth 2.0| O2["自社開発Webアプリ"] EntraID -->|OIDC / OAuth 2.0| O3["モバイルアプリ"] EntraID -->|OIDC / OAuth 2.0| O4["マイクロサービスAPI"]

5.2 エンタープライズアプリの設定方針

SAMLを選ぶ場合

  • ギャラリーアプリ（Salesforce、ServiceNow、Workday等）の多くがSAML対応
  • オンプレミスのWebアプリ（SharePoint On-Premises等）
  • SAML専用のSaaSへの接続

OIDCを選ぶ場合

  • 新規開発のWebアプリ・APIをMicrosoft Identityプラットフォームと統合
  • MSAL（Microsoft Authentication Library）を使った実装
  • Microsoft Graphへのアクセスが必要なアプリ

5.3 Entra IDのエンドポイント

プロトコルエンドポイント例
SAML SSOhttps://login.microsoftonline.com/{tenant-id}/saml2
OIDC 認可https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
OIDC トークンhttps://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
OIDC ディスカバリーhttps://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration

6. 導入時の選択フロー

以下のフローに沿って、どちらのプロトコルを使うべきかを判断できます。

flowchart TD Start([アプリ連携を検討]) --> Q1{接続先アプリは
既存のSaaSか？} Q1 -->|Yes| Q2{そのSaaSは
SAMLのみ対応？} Q1 -->|No 自社開発| Q3{対象はブラウザ
アプリか？} Q2 -->|Yes| SAML1[SAMLを使用] Q2 -->|No 両対応| Q4{新規か既存か？} Q4 -->|新規| OIDC1[OIDCを推奨] Q4 -->|既存でSAML設定済| SAML2[SAMLを継続] Q3 -->|Yes Webアプリ| Q5{SPA / SSR？} Q3 -->|No モバイル・API| OIDC2[OIDCを使用
PKCEを必ず有効化] Q5 -->|SPA| OIDC3[OIDCを使用
PKCE + Authorization Code] Q5 -->|SSR サーバーサイド| OIDC4[OIDCを使用
Authorization Code Flow]

7. よくある混同ポイントと注意事項

7.1 「OAuth 2.0」と「OIDC」は違う

よく混同されますが、OAuthとOIDCは別物です。

OAuth 2.0OIDC
目的認可（アクセス権の委任）認証（ユーザーの身元確認）
トークンアクセストークンのみIDトークン + アクセストークン
ユーザー情報仕様に含まれないIDトークン / userinfo エンドポイントで提供

OIDCはOAuth 2.0の上に認証機能を追加したものです。 「OAuth 2.0でログイン」という実装はセキュリティリスクになり得るため、認証にはOIDCを使うことが推奨されます。

7.2 SAMLとOIDCの共存

同じIdP（Entra ID等）から、アプリによってSAMLとOIDCを使い分けることは一般的であり問題ありません。IdP側で各アプリごとに設定します。

7.3 モバイルアプリでのSAMLの限界

SAMLはブラウザのHTTP POSTを前提とした設計のため、ネイティブモバイルアプリでは実装が非常に困難です。モバイルアプリでは必ずOIDCを使用してください。

8. まとめ

観点SAML 2.0OIDC
生まれた時代エンタープライズWeb全盛期（2005年）クラウド・モバイル時代（2014年）
得意な場面既存エンタープライズSaaS連携新規開発・モバイル・API
データ形式XML（重い・複雑）JSON/JWT（軽量・シンプル）
設定難易度高（XMLメタデータ交換）低（ディスカバリーで自動設定）
モバイル対応不向き最適
マイクロサービス不向き最適
エンタープライズSaaS最適対応製品は増加中

選択の基本方針

  • 既存のエンタープライズSaaSとのSSO → SAML（相手の対応状況に合わせる）
  • 新規Webアプリ・モバイルアプリ・API → OIDC
  • Azure Entra IDとMicrosoftエコシステム → OIDC（MSAL使用）
  • どちらか選べるなら → OIDCを推奨（シンプルで現代的）

両プロトコルとも成熟した標準であり、Azure Entra IDをはじめとする主要IdPはどちらもサポートしています。既存資産とのバランスを取りながら、新規開発ではOIDCへの移行を進めていくのが現実的なアプローチです。

参考リソース

ホームへ戻る

Built with Hugo & PaperMod

Optimized for Raspberry Pi Zero