SAML と OIDC のどちらを選ぶべきか – 認証方式を選んだだけで安全になるわけではない

Web サービスや業務システムにシングルサインオンを導入する場合、代表的な選択肢として SAML と OpenID Connect（OIDC）があります。

SAML は企業向けの認証連携で長く利用されてきた方式であり、OIDC は OAuth 2.0 を基盤として設計された認証プロトコルです。新規システムを設計する場合、現在は OIDC を第一候補とすることが多いでしょう。一方で、既存の企業向け SaaS や認証基盤との連携では、現在でも SAML が利用されています。

ここで注意したいのは、SAML と OIDC のどちらが絶対的に安全か、という単純な比較ではありません。重要なのは、プロトコルの選択だけで認証機構の安全性が決まるわけではなく、アプリケーション、セッション管理、認可、鍵管理、アカウント管理、監査まで含めた全体設計によって決まるという点です。

SAML と OIDC の基本的な違い

SAML と OIDC は、どちらも外部の認証基盤を利用してユーザー認証を行うための仕組みです。ただし、通信方式、データ形式、想定される利用環境には大きな違いがあります。

項目	SAML 2.0	OpenID Connect
主な用途	企業向け Web SSO	Web、SPA、モバイル、API 連携
基盤技術	SAML 独自仕様	OAuth 2.0
データ形式	XML	JSON、JWT
認証結果	SAML Assertion	ID Token
利用側の呼称	Service Provider（SP）	Relying Party（RP）
認証側の呼称	Identity Provider（IdP）	OpenID Provider（OP）
ブラウザーの役割	認証要求と認証結果を搬送する	Authorization Code を搬送する
サーバー間通信	一般的な POST Binding では必須ではない	Authorization Code Flow では必要
API との親和性	低い	高い
新規アプリとの親和性	低め	高い

SAML は、主としてブラウザーベースの Web SSO を目的として設計されています。OIDC は、Web アプリケーションだけでなく、モバイルアプリ、SPA、API Gateway、マイクロサービスなどを含む現在のアプリケーション構成に適合しやすい仕組みです。

SAML ではブラウザーが IdP と SP を橋渡しする

SAML の特徴の一つは、認証要求と認証結果をユーザーのブラウザーが運ぶことです。一般的な SP Initiated SSO では、ユーザーが SP へアクセスし、SP が SAML AuthnRequest を付けて IdP へリダイレクトし、IdP がユーザーを認証した後、SAML Response を含む HTML フォームをブラウザーへ返します。最後に、ブラウザーが SAML Response を HTTP POST で SP へ送信し、SP が検証してログインを成立させます。

段階	通信	意味
1	ブラウザーから SP	ユーザーがサービスへアクセスする
2	SP からブラウザー経由で IdP	認証要求を IdP へ送る
3	IdP	ユーザーを認証し、SAML Response を生成する
4	IdP からブラウザー	SAML Response を含むフォームを返す
5	ブラウザーから SP	SAML Response を POST する
6	SP	署名、宛先、有効期限などを検証する

IdP と SP が認証結果を直接交換するのではなく、ブラウザーが中継します。ネットワーク構成として見ると、利用者端末から IdP と SP の両方に到達できれば、IdP と SP の間に直接の通信経路がなくても SSO を成立させやすい方式です。この構成は現在の感覚では少し特殊に見えますが、組織境界やファイアウォールを越えて Web SSO を実現する仕組みとしては合理的です。

ただし、ブラウザーは信頼できる通信主体ではありません。ブラウザーを経由する SAML Response は、ユーザー側から参照や改変を試みることができます。そのため、SP は受信した SAML Response を厳密に検証する必要があります。

• XML 署名が正しいこと
• 信頼している IdP が署名していること
• Audience が対象の SP を示していること
• Destination や Recipient が正しいこと
• Assertion が有効期間内であること
• InResponseTo が送信した認証要求と対応していること
• 同一 Assertion が再利用されていないこと

SAML は、ブラウザーを信頼する方式ではありません。ブラウザーを搬送路として利用しながら、署名と検証条件によって信頼性を確保する方式です。

OIDC ではブラウザーとバックチャネルを使う

OIDC の Authorization Code Flow も、認証フローの前半ではブラウザーを利用します。ただし、ブラウザーが運ぶものは認証結果そのものではなく、短時間だけ有効な Authorization Code です。

段階	通信	意味
1	ブラウザーから RP	ユーザーがアプリケーションへアクセスする
2	RP からブラウザー経由で OP	Authorization Request を送る
3	OP	ユーザーを認証する
4	OP からブラウザー経由で RP	Authorization Code を返す
5	RP から Token Endpoint	Authorization Code を Token と交換する
6	OP から RP	ID Token や Access Token を返す

OIDC の Authorization Code Flow では、RP と OpenID Provider 間に直接通信が必要です。一般的には、Token Endpoint、JWKS Endpoint、Discovery Endpoint へ HTTPS で到達できる必要があります。Token Endpoint では Authorization Code を ID Token や Access Token へ交換し、JWKS Endpoint では ID Token の署名を検証するための公開鍵を取得し、Discovery Endpoint では認証基盤が提供する各エンドポイントや対応機能を取得します。

方式	必要な到達性
SAML の一般的な Web SSO	利用者端末から IdP と SP へ到達できること
OIDC Authorization Code Flow	利用者端末から OP と RP へ到達でき、RP から OP の各エンドポイントへ到達できること

OIDC ではバックチャネル通信が増えるため、ネットワーク要件は SAML より多くなります。一方で、ブラウザーには認証結果そのものではなく Authorization Code だけを通し、Token は RP が直接取得できます。この構成は、現在の Web アプリケーションや API 連携に適しています。

SAML はセキュリティが高いという幻想

SAML には、企業向け認証、XML 署名、証明書、IdP と SP 間の信頼関係といった要素があります。そのため、SAML は堅牢でセキュリティが高い方式だという印象を持たれやすい傾向があります。しかし、SAML を採用しただけでセキュリティが高くなるわけではありません。

SAML は仕様が複雑であり、実装や設定を誤ると、XML 署名の検証対象を誤る、署名された要素とアプリケーションが参照する要素が一致しない、XML Signature Wrapping への対策が不十分になる、Audience や Destination を検証しない、InResponseTo を検証しない、Assertion のリプレイを防止しない、といった問題が発生します。

• XML 署名が付いていることだけを確認してしまう
• 署名された Assertion ではなく、別の要素を認証情報として参照してしまう
• Assertion と Response の署名要件が曖昧になる
• 証明書ローテーションに失敗する
• RelayState を安全に処理しない
• IdP Initiated SSO を無条件に信頼する

SAML では、XML 署名が付いていることだけを確認すればよいわけではありません。どの要素に署名されているか、アプリケーションがどの要素を認証情報として使用するか、その両者が一致しているかを確認する必要があります。SAML は古いから危険なのではなく、正しく実装、設定、運用するために相応の知識が必要な方式です。

OIDC も採用しただけでは安全にならない

OIDC を採用すれば自動的に安全になるわけでもありません。OIDC は JSON や JWT を利用し、現在の開発環境に適合しやすい方式ですが、開発者にとって理解しやすいことと、安全であることは同じではありません。

• Redirect URI を厳密に制限する
• state を検証する
• nonce を検証する
• PKCE を利用する
• ID Token の署名を検証する
• iss、aud、exp、iat を検証する
• ID Token と Access Token を混同しない
• Refresh Token を安全に保存する
• Token をブラウザーの危険な保存領域へ置かない
• ログアウトとセッション失効を適切に実装する

OIDC の ID Token は、ユーザーが OpenID Provider によって認証されたことを RP へ伝えるためのものです。OpenID Connect Core でも、ID Token の iss、aud、exp、iat などの検証が重要な要素として定義されています。標準的なライブラリやフレームワークを利用し、仕様に沿った検証を実装する必要があります。

認証プロトコルとアプリケーションセッションは別である

OIDC や SAML による認証が成功した後、多くの Web アプリケーションでは独自のセッションを生成します。このとき、認証プロトコルが安全でも、アプリケーション側のセッション管理が不適切であれば、システム全体としては安全ではありません。

• セッション Cookie に Secure 属性がない
• HttpOnly 属性がない
• SameSite 属性が適切でない
• 認証後にセッション ID を再生成しない
• セッションの有効期限が長すぎる
• ログアウトしてもセッションが残る
• IdP 側でアカウントを停止しても既存セッションが継続する
• 権限変更が既存セッションに反映されない
• Token の有効期限とアプリケーションセッションの有効期限が一致しない

ID Token を受け取った後、アプリケーションがどのようなセッションを作成し、どれだけ維持し、どの条件で失効させるかは、アプリケーション側の設計です。認証プロトコルは、ユーザー認証、認証結果の検証、アプリケーションセッション確立、認可、セッション更新、失効、ログアウト、監査という流れの一部にすぎません。

認証と認可を混同しない

SAML や OIDC によってユーザーの認証が成立しても、そのユーザーがすべての操作を実行できるわけではありません。認証は、ユーザーが誰であるかを確認する処理です。認可は、そのユーザーが何を実行できるかを判断する処理です。

たとえば、OIDC で正常にログインできたとしても、アプリケーション側では一般ユーザーと管理者を区別し、所属組織やテナントを確認し、操作対象のデータに対する権限を確認し、API ごとに必要な権限を確認する必要があります。ロールやグループ情報を利用する場合も、Claim の発行元と意味を確認しなければなりません。

特にマルチテナントシステムでは、認証済みであることだけを確認し、テナント ID やデータ所有者を十分に検証しない実装が重大な情報漏えいにつながります。プロトコルの選択よりも、認証後の認可設計の方がシステム全体の安全性に大きな影響を与える場合もあります。

危険なのはプロトコルとアプリケーションの境界である

認証基盤そのものよりも、認証基盤とアプリケーションの境界で問題が起きることがあります。SAML と OIDC のどちらを選んだかではなく、認証結果をどこで検証し、どの情報をアプリケーションへ渡し、どこを信頼境界にするかが問題になります。

境界	主な問題
IdP とアプリケーション	Claim や属性の誤解釈
Token とアプリケーションセッション	有効期限や失効条件の不整合
認証と認可	ログイン済みであることを権限確認の代わりにする
リバースプロキシとアプリケーション	認証済みヘッダーの偽装
フロントエンドとバックエンド	Token 漏えい、XSS、CSRF
アカウント管理とセッション	アカウント停止後も利用可能
IdP のグループとアプリ権限	グループ名や Claim の意味が一致しない
複数テナント	テナント境界の検証不足

たとえば、リバースプロキシが認証したユーザー情報を HTTP ヘッダーでバックエンドへ渡す構成では、バックエンドへの直接アクセスを遮断する必要があります。外部から同じヘッダーを自由に付与できる状態では、認証プロキシを通過していない通信が認証済みとして扱われる可能性があります。このような問題は、SAML と OIDC のどちらを選んだかでは解決しません。

現在の新規設計では OIDC を優先する

SAML と OIDC のどちらも、正しく実装すれば認証連携に利用できます。その上で、新規システムを自由に設計できる場合は、OIDC を第一候補とするのが自然です。

• JSON や JWT を利用するため、現在の開発環境と相性がよい
• Web アプリケーションだけでなく、SPA やモバイルアプリにも適用しやすい
• OAuth 2.0 と組み合わせて API 認可へ展開できる
• Discovery や JWKS によって設定と鍵配布を自動化しやすい
• 多くのアプリケーションフレームワークが標準対応している
• Kubernetes やクラウドネイティブ環境と統合しやすい
• API Gateway やマイクロサービスとの連携がしやすい

SAML は Web SSO として完成度の高い仕組みですが、API 連携やモバイルアプリを含むシステム全体へ拡張する場合は、OIDC の方が自然です。特に、新しいアプリケーションに SAML を採用し、その後 API 認可のために OAuth 2.0 を別途追加する構成では、認証方式が複雑になります。最初から OIDC と OAuth 2.0 を前提に設計した方が、認証と API 認可の関係を整理しやすくなります。

事情があれば SAML を選んでもよい

OIDC が現在の第一候補であっても、SAML を選ぶこと自体が誤りではありません。接続先の SaaS が SAML にしか対応していない、既存 IdP が SAML を中心に構築されている、既存の属性マッピングや運用手順を継承する必要がある、組織内の標準方式が SAML である、といった状況では、SAML は合理的な選択です。

• 接続先の SaaS が SAML にしか対応していない
• 既存 IdP が SAML を中心に構築されている
• 既存の属性マッピングや運用手順を継承する必要がある
• 組織内の標準方式が SAML である
• 既存の SAML 連携を OIDC へ変更する費用が大きい
• Web ブラウザーベースの SSO だけで要件を満たせる
• IdP と SP 間の直接通信を避ける必要がある

既存システムの事情を無視して、モダンであることだけを理由に OIDC へ変更する必要はありません。方式を変更すると、アプリケーション改修、試験、運用手順変更、障害対応、監査対応、利用者への影響などが発生します。OIDC への移行によって得られる効果より、移行コストやリスクが大きい場合は、SAML を継続する方が適切です。

選定理由をセキュリティの強弱だけで説明しない

SAML と OIDC の選定では、どちらのセキュリティが強いかという説明だけに依存しない方がよいでしょう。実際の選定基準は、アプリケーション構成、既存基盤、連携先、ネットワーク要件、運用コストによって決まります。

条件	選択の方向性
新規 Web アプリケーション	OIDC を優先
SPA やモバイルアプリ	OIDC
API 連携を含む	OIDC と OAuth 2.0
Kubernetes やクラウドネイティブ環境	OIDC を優先
既存企業 SaaS との SSO	SAML も有力
既存 SAML 基盤を継承	SAML 継続も合理的
ブラウザーから IdP と SP にだけ到達可能	SAML が適合する場合がある
既存連携の変更コストが大きい	無理に変更しない

SAML を選ぶ理由は、SAML の方が強固だからではなく、既存環境や接続先との互換性が必要だから、という説明の方が正確です。OIDC を選ぶ理由も、OIDC であれば安全だからではなく、現在のアプリケーション構成に適合し、標準的な実装や運用を行いやすいから、と説明するべきです。

プロトコルを選んだだけで盤石だと思わない

SAML を採用し、XML 署名を有効にしただけで、認証機構が完成するわけではありません。OIDC を採用し、Authorization Code Flow と PKCE を利用しただけでも、認証機構が完成するわけではありません。

設計要素	確認すること
認証プロトコル	SAML か OIDC か、どのフローを使うか
認証結果の検証	Assertion または Token の署名、宛先、有効期限、発行元を確認する
鍵と証明書の管理	ローテーション、失効、公開鍵取得、信頼先を管理する
アプリケーションセッション	Cookie 属性、有効期限、再生成、失効条件を設計する
認可	ロール、テナント、データ所有者、API 権限を確認する
アカウント管理	停止、権限変更、既存セッションへの反映を設計する
信頼境界	プロキシ、ヘッダー、バックエンド直アクセスを制御する
ログと監査	認証成功、失敗、権限変更、異常操作を追跡する
脆弱性管理	ライブラリ、製品、設定の更新を継続する

認証方式の選定は重要ですが、それはセキュリティ設計の開始点です。プロトコル名を決めることが、セキュリティ設計の完了ではありません。

まとめ

現在の新規システムでは、特別な制約がなければ OIDC を優先する判断が妥当です。OIDC は、現在の Web アプリケーション、API、SPA、モバイル、Kubernetes、クラウドネイティブ環境と統合しやすく、標準的なライブラリや製品も充実しています。

一方で、既存の企業向け SaaS や IdP との連携、組織内の標準、移行コスト、ネットワーク制約などの事情があれば、SAML を選んでも問題ありません。重要なのは、SAML を選んだから安全である、OIDC を選んだから安全である、と考えないことです。

SAML と OIDC のどちらを採用しても、認証結果の検証、セッション管理、認可、失効、アカウント管理、信頼境界、監査まで含めて設計する必要があります。認証方式は、システム全体のセキュリティを構成する一つの要素です。方式の新旧や名称ではなく、認証から認可、セッション、失効、運用までを一つの仕組みとして評価することが重要です。

参考情報

• OASIS – SAML 2.0 Technical Overview
• OpenID Foundation – OpenID Connect Core 1.0
• RFC 9700 – Best Current Practice for OAuth 2.0 Security
• OWASP Cheat Sheet Series – Session Management Cheat Sheet