SAMLは、企業向けシングルサインオン（SSO）を可能にする認証とフェデレーションのプロトコルです。一方OAuth 2.0は、アクセストークンを用いてAPIへの委任アクセスを許可する認可フレームワークです。

認証と認可はアイデンティティとアクセス管理（IAM）の基盤ですが、それらを実現するプロトコル（SAMLやOAuth 2.0など）は、関連しつつも異なる目的を果たします。これらを混同すると、セキュリティ上のギャップやアーキテクチャ上の不要なリスクが生じます。

例：あなたの会社が、Salesforce、Slack、社内HRポータルを使用しているとします。SAMLを使用すると、企業ディレクトリに一度ログインするだけで、3つすべてに対して認証されます（エンタープライズSSO）。一方、パスワードを共有せずにサードパーティのアナリティクスツールにSalesforceデータへのアクセスを許可したい場合は、OAuth 2.0を使用します。OAuth 2.0は、特定のリソースに対する委任認可を提供します。

SAML 2.0

• ユーザーを認証し、エンタープライズSSOを可能にする
• 「このユーザーは誰か？」に答える
• アイデンティティ属性を含むXMLアサーションを使用する
• 最適な用途：エンタープライズフェデレーション、従業員向けSSO

OAuth 2.0

• 認証情報を共有せずにリソースへのアクセスを認可する
• 「このユーザーは何にアクセスできるか？」に答える
• API認可のためにアクセストークン（必要に応じてリフレッシュトークン）を発行する
• 最適な用途：APIセキュリティ、モバイルアプリ、サードパーティアクセス

OpenID Connect（OIDC）は、OAuth 2.0ベースのアイデンティティレイヤーで、IDトークンによる認証機能を追加します。

どちらもオープン標準ですが、その目的は異なります。SAML 2.0は、認証（AuthN）とSSOに重点を置き、「このユーザーは誰か？」という質問に答えます。一方、OAuth 2.0は認可（AuthZ）に重点を置き、「このユーザーは何にアクセスできるか？」という質問に答えます。

SAMLは、企業や政府機関のコンテキストにおけるアイデンティティ連携のために設計されています。OAuth 2.0は、委任アクセス向けに設計された認可フレームワークで、最新のAPIや消費者アプリケーションの保護によく使用されています。

• SAML 2.0（OASIS標準、2005）
• OAuth 2.0（IETF RFC 6749、2012）
• OpenID Connect（OpenID Foundation、2014）

項目	SAML 2.0	OAuth 2.0
主な目的	認証とエンタープライズSSO	認可と委任アクセス
データ形式	XML（セキュリティアサーション）	トークン形式に依存せずに、ほとんどの実装では、JWTが使用されるが、不透明なトークンもサポートされる
主要なアーティファクト	署名付きXMLアサーション、フェデレーションメタデータ（帯域外）	アクセストークン、スコープ
IDの受け渡し	組み込み：アサーションは、明示的にID属性（ロールやメールアドレスなど）を保持する	組み込みでない：アクセストークンは認可のみを証明する。OpenID Connectによって、IDクレームが追加される
導入	エンタープライズ従業員のID、レガシーシステム	API、モバイルアプリ/ネイティブアプリ、マイクロサービス
トークンの複雑さ	高い（XML解析、デジタル署名）	中程度（JWTでは署名、クレーム、キーのライフサイクル検証が必要、不透明なトークンではイントロスペクションが必要）

SAMLは、セキュリティアサーションにXMLを使用します。XMLは解析と署名の検証に追加のオーバーヘッドが必要になるため、メッセージサイズが大きくなり、高スループット環境でのパフォーマンスに影響する可能性があります。

OAuth 2.0は、トークン形式を規定していません。JSON Web Token（JWT）が一般的ですが、必須ではありません。JWTはコンパクトかつ軽量であり、通常は署名検証、クレーム検証、およびキーローテーションによって検証されるため、モバイルアプリケーションやAPI認可のスケーリングに最適です。不透明なトークンが使用される場合、検証はローカルでの署名チェックではなく、トークンイントロスペクションによって実行されます。

主な違いは、各プロトコルの主要なアーティファクトが何を証明するかにあります。

SAMLアサーションは、アイデンティティプロバイダー（IdP）によって発行される、ユーザーのアイデンティティと属性を直接示すステートメントです。アプリケーションは、このアサーションを信頼して、ユーザーのアイデンティティとそのユーザーが属するグループを確認することができます。

OAuth 2.0アクセストークンは、特定のリソースへのアクセス認可を証明するだけで、アイデンティティを証明するものではありません。OIDCなどの拡張機能を使用せずに、OAuth 2.0のみを認証に使用すると、アクセストークンがユーザーの本人確認を行わないため、セキュリティ上のギャップが生じます。

各プロトコルは、処理の流れが根本的に異なります。

• SAMLは、メタデータ交換によって事前に確立された信頼を重視し、ブラウザリダイレクトを介して署名付きXMLアサーションでアイデンティティデータを直接返します。
• OAuth 2.0は、認可コードを中間ステップとして用いて、クライアントがバックエンドエンドポイントでコードをトークンと交換することで、ブラウザに公開することなく安全なトークン配信を可能にします。

SAMLを使用する状況

エンタープライズSSOの要件

• ID管理の一元化
• 複数のビジネスアプリケーションにおけるシームレスなSSO
• 詳細なユーザー属性の交換（部門、ロール、グループ）

規制遵守

• 可監査性とガバナンスのための組み込み属性ステートメント
• コンプライアンス報告のための明示的なIDデータ共有

企業と政府機関の連携
SAMLは、最新エンタープライズプラットフォームからレガシーシステムまで、企業と政府機関のアイデンティティ連携で広く使用されています。企業と政府のアイデンティティプラットフォームは通常、さまざまな統合要件に対応するためにSAMLとOIDCの両方をサポートしています。

OAuth 2.0を使用する状況

APIセキュリティ

• きめ細かいアクセスコントロールのためにスコープを使用したREST APIの保護
• マイクロサービスのステートレス認可
• トークンベースのAPIセキュリティ

モバイルアプリとネイティブアプリ

• 軽量なJSON形式と、Proof Key for Code Exchange（PKCE）を用いた認可コード
• 組み込みWebビューではなく、システムブラウザを使用した安全なブラウザベースのリダイレクト

サードパーティアクセス

• 認証情報を共有しない特定権限の委任
• ソーシャルログイン（Google、Facebookでのサインイン）
• ユーザーデータへの限定的なスコープアクセス

OIDCは、OAuth 2.0上に構築されたアイデンティティレイヤーです。ユーザー認証にIDトークンを導入し、IDクレームの表現方法を標準化すると同時に、引き続きOAuth 2.0を使用して、API認可のためのアクセストークンを発行します。OIDCは、OAuth 2.0を置き換えるのではなく、認証とアイデンティティをサポートするために拡張するものです。最新のフローでは、OIDCは認証でIDトークンを発行し、OAuth 2.0は認可でAPI呼び出し用のアクセストークンを発行します。通常、両者は同じフローで連携して動作します。

機能	OAuth 2.0	OIDC（OAuth 2.0拡張仕様）
主要な出力	アクセストークン（認可）	IDトークン（認証）
アイデンティティ	なし（認可のみ）	あり（IDクレーム、ユーザープロファイル）

1. OAuth 2.0を認証として扱う

• OAuth 2.0のアクセストークンは、アイデンティティではなく認可を証明します
• 認証にはOpenID Connectを使用するか、追加の検証を実装します

2. トークン検証が不十分

• SAML：署名の検証、有効期限条件（NotBefore/NotOnOrAfter）の検証、オーディエンスのチェックを行います
• OAuth 2.0：署名、有効期限（exp）、オーディエンス（aud）、発行者（iss）、必要に応じてnot-before（nbf）を検証します
• 検証方法はトークンの種類によって異なります。JWTはローカルで検証し、不透明なトークンにはイントロスペクションを使用します

3. パブリッククライアントに対して安全でないフローに依存する

• ネイティブアプリケーションは、クライアントシークレットを安全に保存できません（つまり、「パブリック」クライアントです）
• パブリッククライアントには、認可コードの傍受を防ぐために、Authorization Code Flow with PKCEを使用します（暗黙的な許可フローなどのPKCEを用いないフローは非推奨であり、すべての新規開発では使用すべきではありません）

SAMLとOAuth 2.0の主な違いは何ですか？

SAMLは、認証に使用されてユーザーのアイデンティティを判断する一方で、OAuth 2.0は、認可に使用されてユーザーがアクセスできる内容を決定します。SAMLはエンタープライズSSOに、OAuth 2.0はAPIアクセスコントロールに使用されます。

OAuth 2.0はSSOでSAMLの代わりになりますか？

OAuth 2.0は、厳密には認可フレームワークであるため、単独ではSSOでSAMLの代わりにはなりません。OAuth 2.0上に構築されているOIDCは、SSOに必要な認証レイヤーを追加しますが、SAMLと異なり、 Single Logoutの仕様は任意の拡張であり、実装ごとに個別に扱われます。

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

いずれのプロトコルも、正しく実装されていれば強固なセキュリティ保証を提供します。リスクは、署名検証の欠落、トークン有効期間の不適切な処理、オーディエンスと発行者のチェック不備、認可エンドポイントの誤設定などの実装上の欠陥から生じます。SAMLはメッセージレベルの署名と任意の暗号化を提供し、OAuth 2.0はPKCEと適切なトークン検証を組み合わせることで同等のセキュリティを提供します。プロトコルの選択では、セキュリティ上の想定よりもアーキテクチャとの適合性を優先すべきです。

両方のプロトコルをサポートする必要がありますか？

ほとんどのアプリケーションは、内部に両方のプロトコルを必要としません。しかし、外部のアイデンティティプロバイダーと統合する場合には、両方をサポートする必要があるかもしれません。エンタープライズ顧客はSAMLを必須とすることが多く、消費者アプリではOAuth 2.0によるソーシャルログインが期待されています。プロトコル変換は、アイデンティティプラットフォームで行われます。

APIでSAMLよりもOAuth 2.0を優先するのはなぜですか？

APIでOAuth 2.0を優先する理由は、トークンがXMLアサーションよりも小さく解析が容易であり、スコープベースの認可がAPI権限に直接マッピングされ、最新のプログラミング言語でOAuth 2.0ライブラリのサポートが充実しているためです。

SAMLとOAuth 2.0のどちらを選択するかは、アプリケーションの要件と統合シナリオによって異なります。いずれのプロトコルも、正しく実装されていれば、アイデンティティとアクセス管理の安全性が確保されます。

Auth0のようなアイデンティティプラットフォームを使用すると、SAML、OAuth 2.0、OpenID Connectがサポートされることで、プロトコルの複雑さが解消されます。アプリケーションは、基礎となるプロトコルに関係なく、一貫したAPIを通じてユーザーを認証します。「IAM入門」シリーズを参照して、アイデンティティプロトコルと最新の認証アーキテクチャについての理解を深めてください。

詳細を見る

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