SAMLとOpenID Connectはいずれもシングルサインオン（SSO）を実現するためのプロトコルですが、異なるアーキテクチャを前提として設計されています。不適切な認証プロトコルを選択すると、複雑なXML解析や証明書のローテーションに関する課題、モバイルアプリとの連携不足といった問題に直面することになります。

SAML 2.0（OASIS標準、2005年）は、XMLベースのエンタープライズ向けアイデンティティフェデレーションを実現するために設計されました。企業のIdPと連携する従来型のWebアプリが代表的な利用例です。一方、OpenID Connect（OpenID Foundation、2014年）は、OAuth 2.0を拡張して軽量なJSONベースの認証レイヤーを追加したプロトコルで、API、モバイルアプリ、モダンなWebアーキテクチャ向けに最適化されています。どちらを選ぶべきかは、対象となるプラットフォームと既存のアイデンティティ基盤によって決まります。

例：あなたの会社が、あるスタートアップ企業を買収したとします。そのスタートアップのReactアプリでは、Googleを使用して認証する一般ユーザー（OIDC）と、企業のアイデンティティプロバイダー経由で認証する自社従業員（SAML）の両方をサポートする必要があります。IdPが両方のプロトコルに対応していれば、Reactアプリは1つの統合ポイントだけを維持すればよく、OIDCとSAMLの認証フローを個別に実装する必要はありません。

項目	SAML 2.0	OpenID Connect（OIDC）
主な目的	エンタープライズフェデレーション	OAuth 2.0を利用したモダン認証
データ形式	デジタル署名付きXMLアサーション	IDトークンとしてJSON Web Token（JWT）を使用
基盤技術	XMLベースの認証とフェデレーションプロトコル	OAuth 2.0上に構築された認証レイヤー
通信方式	主にHTTP-POSTバインディングとHTTP-Redirectバインディング（Browser SSO Profile）	HTTPSを使用し、フロントチャネルのリダイレクトと、トークンエンドポイントUserInfoエンドポイントへの直接呼び出しを組み合わせる
設定	XMLメタデータの交換、証明書の管理	ディスカバリードキュメント（.well-known/openid-configuration）を利用したクライアント登録
トークン形式	署名付き（必要に応じて暗号化された）XML	IDトークンはJWT。アクセストークンの形式は実装依存（OAuth 2.0/OIDCではJWTアクセストークンは必須ではないが、利用されるケースが増えている）
適した用途	レガシーな政府機関システムや、規制の厳しい業界でフェデレーション要件のある環境	SPA、モバイルアプリ、マイクロサービス、ソーシャルログイン
統合の複雑さ	比較的高い。XML解析、メタデータ管理、証明書ローテーションへの対応が必要	一般的に低い。JSON解析とシンプルなHTTP通信、構成の自動検出機能を利用できる

重要な違い：SAMLアサーションには、複雑なエンタープライズ要件に対応するための豊富な属性階層を含められます。一方、OIDCでは、openid、profile、emailなどのスコープを使用してクレームを要求し、IDトークンや（必要に応じて）UserInfoエンドポイント経由で取得します。

また、SAMLはOAuth 2.0とは独立して動作します。一方、OIDCはOAuth 2.0の認可フローの上に認証機能を追加する形で実装されているため、認証と認可の両方を単一のプロトコルスタックで実現できます。

SAML（SP-Initiatedフロー）：サービスプロバイダー（SP）は、AuthnRequest（認証要求）を添えてユーザーをIdPへリダイレクトします。IdPはユーザーを認証し、ユーザー属性を含む署名付きアサーションを生成した後、HTTP-POSTを使用してSPのACS（Assertion Consumer Service）へ返します。SPは署名とアサーション条件を検証し、アクセスを許可します。このフローでは通常、複数回のブラウザリダイレクトが発生し、XMLの処理も必要になります。

OIDC（PKCEを使用したAuthorization Code Flow）：アプリは、必要なスコープとPKCEのコードチャレンジを含めて、ユーザーをIdPの認可エンドポイントへリダイレクトします。認証とユーザーの同意が完了すると、IdPは認可コードを返します。アプリは、この認可コードとPKCEベリファイアを使用して、IDトークンとアクセストークンを取得します。また、クライアントの種類やIdPのポリシーによっては、リフレッシュトークンも受け取ることがあります。その後、JWTの署名を検証し、クレーム（iss、aud、exp）を確認すれば認証処理は完了です。最新のプラットフォームではJSONやJWTが標準でサポートされているため、一般的にこのフローはSAMLに比べて実装が容易です。

アーキテクチャに応じて適切なプロトコルを選択しましょう。

次のような場合はSAMLを選択します。

• 既存のエンタープライズ向けIdPと連携する場合
• FISMA、FedRAMP、または従来のSAMLベースのフェデレーションが求められる政府機関や規制の厳しい業界向けのシステムを構築する場合
• すでにSAMLを利用しているシステムと連携しており、移行コストがメリットを上回る場合
• 複雑なユーザー属性情報（入れ子になった組織階層やカスタムクレームなど）を扱う必要がある場合

次のような場合はOIDCを選択します。

• シングルページアプリケーション（React、Vue、Angular）やモバイルアプリ（iOS、Android）を開発する場合
• ソーシャルログインプロバイダー（Google、GitHub、Apple）を追加する場合
• OAuth 2.0のアクセストークンを必要とするAPIファーストのアーキテクチャやマイクロサービスを作成する場合
• レガシーシステムによる制約がなく、新規にシステムを構築する場合。OIDCは設定が比較的シンプルなため、本番稼働までの期間を短縮可能
• より充実したライブラリとドキュメントを活用し、開発者エクスペリエンスを重視する場合

両方必要な場合には、IdPはプロトコル変換を行えます。アプリケーション側からはOIDCのみを利用しながら、SAMLベースのエンタープライズIdPと連携できます。そのため、2つのプロトコル実装を個別に管理する必要はありません。

トークンの検証

• OIDCの場合：IdPが公開しているJSON Web Key Set（JWKS）を使用してJWTの署名を検証し、有効期限（exp）を確認するとともに、対象者（aud）が自分のクライアントIDと一致していること、発行者（iss）が利用しているIdPと一致していることを検証します。
• SAMLの場合：XML署名を検証し、有効期限に関する条件（NotBefore、NotOnOrAfter）を確認するとともに、Audience制約を検証します。

クライアント構成

SPAやモバイルアプリにクライアントシークレットを埋め込んではいけません。クライアントシークレットは、ブラウザの開発者ツールやアプリのバイナリから参照できてしまうためです。Authorization Code Flowでは、PKCE（Proof Key for Code Exchange）を使用してください。PKCEは、シークレットを必要とせずに認可コードの横取りを防ぐ仕組みであり、パブリッククライアントでは必須とされています（RFC 7636）。

セッション管理

OIDCは、長期間のセッションのためにOAuth 2.0からリフレッシュトークンのサポートを継承しています。IdPがリフレッシュトークンを発行し、クライアントの構成で利用が許可されている場合は、アクセストークンの有効期限が切れた際にリフレッシュトークンを使用して新しいアクセストークンを取得できます。一方、SAMLには標準化されたリフレッシュの仕組みがなく、セッションは主にIdPとSPによって管理されます。また、オプション機能としてシングルログアウト（SLO）をサポートしていますが、その実装方法はIdPごとに異なり、標準化が難しい場合があります。

エラー処理

認証失敗時には、デバッグに役立つよう、コンテキスト情報（タイムスタンプ、エラーコード、クライアントID、IdPからの応答など）を含めてログを記録してください。ユーザーには、「認証に失敗しました」といった一般的なメッセージを表示するようにします。攻撃者に有益な情報を与えないため、トークンの詳細情報、クレームの不一致、署名検証の失敗などをユーザーに公開しないようにしてください。

OpenID ConnectはSAMLに取って代わるのでしょうか？

いいえ、両者は共存しています。OIDCはOAuth 2.0を基盤としているため、消費者向けアプリやモバイルアプリ開発の分野で急速に普及しています。しかし、SAMLはインフラへの既存投資やコンプライアンス要件（FISMA、FedRAMPなど）を背景に、エンタープライズ分野や政府機関における標準として引き続き利用されています。ほとんどの組織では両方のプロトコルを併用しており、新しいアプリケーションにはOIDCを、エンタープライズ向けフェデレーションにはSAMLを使用しています。

どちらのプロトコルがより安全ですか？

どちらも、適切に実装されていれば高いレベルのセキュリティを実現できます。SAMLはXML署名とオプションの暗号化を使用し、OIDCはJWT署名とHTTPSを使用します。大きな違いは、OIDCにはPKCE拡張（RFC 7636）があり、クライアントシークレットを安全に保管できないパブリッククライアント（モバイルアプリやSPAなど）を保護できる点です。SAMLでも、Artifact BindingやHolder-of-Key Assertionを利用することで同様の保護を実現できますが、これらの手法は現代的なアプリケーション開発ではあまり一般的ではありません。セキュリティは選択するプロトコルそのものではなく、実装方法によって決まります。

なぜモバイルアプリではSAMLよりOIDCが好まれるのですか？

OIDCのPKCEを使用したAuthorization Code Flowは、クライアントシークレットを安全に保管できない、モバイルアプリのようなパブリッククライアント向けに設計されています。OIDCのJSONトークンはモバイル向けSDKとネイティブに統合できますが、SAMLではXML処理ライブラリが必要になります。また、OIDCはカスタムURIスキーム（iOS）やApp Links（Android）を利用したシームレスな認証をサポートしています。主要なプロバイダーも、モバイル認証については主にOIDCベースのフローをサポートしています。

SAMLからOIDCへの最適な移行方法はどのようなものですか？

段階的に移行することをおすすめします。既存のSAML連携は維持しながら、新しいアプリケーションにはOIDCを導入してください。また、プロトコル変換をサポートするアイデンティティプラットフォームを利用すれば、アプリケーションはOIDCを使用しながら、SAMLベースのエンタープライズIdPと連携できます。そうすれば、既存のフェデレーション関係を損なわずに、リスクを最小限に抑えられます。多くの企業が移行期間中はハイブリッド環境を運用しています。プロトコル変換機能を備えたアイデンティティプラットフォームを利用すれば、アプリケーションはOIDCを使用しつつ、SAMLフェデレーションの管理をプラットフォーム側に任せられます。

OAuth 2.0とOIDCの違いは何ですか？

OAuth 2.0は、アクセストークンを使用して認可（APIへのアクセス権）を処理する仕組みです。一方でOIDCは、OAuth 2.0の上に構築されており、IDトークンを利用した認証（ユーザーの本人確認）の機能が追加されています。たとえば、「Googleでログイン」を実装する場合、認証にはOIDCを使用し、APIへのアクセスにはOAuth 2.0を使用します。OIDCは、標準化されたアイデンティティクレームとUserInfoエンドポイントによって、OAuth 2.0を拡張します。

認証アーキテクチャのセキュリティを確保するうえで、SAMLとOIDCのどちらを選択するかは重要な判断です。どちらのプロトコルでも、トークン検証、証明書管理、セッション管理などを適切に実装する必要があります。また、両方のプロトコルを実装して維持管理することは容易ではありません。

Auth0ではSAMLとOIDCの両方をサポートし、プロトコル変換やセキュリティのベストプラクティスに対応しているため、開発者はアプリケーション機能に集中できます。

アイデンティティとアクセス管理に関連するその他のトピックについては、「IAM入門」シリーズをご覧ください。

詳細を見る

これらの資料は一般的な情報提供のみを目的としています。本資料の利用者は、自身の責任において、自身の専門アドバイザーからセキュリティ、プライバシー、コンプライアンス、またはビジネスに関する助言を得るものとし、本資料に記載された情報のみに依存すべきではありません。