SAML vs. OAuth 2.0：認証と認可における２つのスタンダードを理解して比較する

SAML vs. OAuth 2.0: Mastering the Key Differences

2025/06/13 SecurityBoulevard — 月曜日の朝の、こんな状況を想像してほしい。コーヒーを飲み、デスクに座り、PC を開く。まずはメールにログイン。次にプロジェクト管理ツールを起動する。最初のタスクに取り掛かる前に、迷路のようなログイン画面をくぐり抜け、何度もパスワードを入力していく。こんな日常があるはずだ。

デジタル化が進む現代社会で、私たちは、数え切れないほど多くのアプリケーションにアクセスしている。膨大な認証情報の管理は面倒なだけではなく、セキュリティ・リスクにもつながる。そこで、Single Sign-On (SSO)  のようなテクノロジーが役に立つ。SSO は、１回のログインを介することで、複数の承認済みアプリケーションへのアクセスが許可されるという、心地よい世界を実現してくれる。こうした、SSO とセキュア・アクセスの文脈でよく話題に上がるのは、２つの主要な技術 SAML と OAuth 2.0 である。

しかし、これらは、いったい何なのだろうか？ 互換性はあるのだろうか？ OAuth 2.0 は、誰もが望む SSO エクスペリエンスを実現するために、SAML の代わりに使用できるのだろうか？ しばしば混乱を招く、これらの標準を理解し、SAML と OAuth 2.0 の主な違いを探る旅に出よう。

基本を理解する：認証と認可

SAML と OAuth について詳しく説明する前に、この２つの基本的な概念を明確にしておこう。

認証 (AuthN：Authentication) とは？

認証という、自分が誰であるかを証明する行為について考えてみよう。それは、クラブの警備員に、運転免許証を見せるようなものだ。つまり、身元を確認してもらう行為だ。通常のデジタルの世界では、ユーザー名とパスワード／指紋／多要素認証プロンプトへの応答などを伴う。

認可 (AuthZ：Authorization) とは？

その一方で、認可とは、身元が確認された後に、何ができるかということだ。警備員は、あなたをクラブに入場させるが (認証)、VI P専用ラウンジエリアへのアクセスは VIP リストバンド (許可) により認められる。オンラインでは、この認可により、特定ファイルの閲覧／ドキュメントの編集／アプリ内での管理設定へのアクセスなどが、可能かどうか判断される。

Single Sign-On (SSO) とは？

Single Sign-On (SSO) とは、単一の認証情報で、いったんログインしたユーザーが、複数種のソフトウェアごとに再度ログインすることなく、アクセスできるというシステムである。つまり、認証情報の管理が簡素化され、ユーザー・エクスペリエンスが効率化していく。

ここまで、基本を説明したので、次は SAML と OAuth を見ていこう。

SAML 2.0 の詳細：SSO を実現するエンタープライズの主力製品

SAML とは？

SAML は Security Assertion Markup Language の略であり、主として認証と Web ベースの SSO の実現に用いられるオープン・スタンダードである。OASIS の Security Services Technical Committee により開発された SAML は、各種のセキュリティ・ドメイン間でのユーザー認証／承認データの交換を可能にする。

デジタル・パスポートの発行機関のようなものだと考えてみてほしい。信頼できるエンティティ (ID プロバイダ) がユーザーの ID を確認し、他のサービス (サービス・プロバイダ) が信頼する、安全なアサーション (パスポートのスタンプのようなもの) を発行する。

SAML の主要プレーヤー：
  • ユーザー (Principal)：サービスにアクセスしようとするユーザー。
  • ID プロバイダ (Idp)：ユーザーを認証し、SAML アサーションを発行するシステム (Okta、Azure AD、Google Workspace など)。
  • サービス・プロバイダ (SP)：ユーザーがアクセスする、アプリまたは Web サイト (Salesforce／Slack／カスタム社内アプリなど)。

通常において、SAML アサーションは XML 形式で記述され、整合性と信頼性を確保するためのデジタル署名を有している。

SAML の仕組み：簡略なフロー

たとえば、会社の経費報告ツール (SP) にアクセスしたいとする。

  1. 経費報告ツールのログイン・ページに移動する。
  2. このツールはユーザーがログイン前であることを認識し、社内のセンタライズされたログイン・ポータル (Idp) へと、そのユーザーの Web ブラウザをリダイレクトする。
  3. ユーザーは IdP のログイン・ページに、会社から発行された認証情報 (ユーザー名／パスワード／MFA) を入力する。
  4. IdP は、そのユーザーを認証する。
  5. IdP は、デジタル署名された SAML アサーション (ユーザーの ID 情報と承認の詳細を含む XML ドキュメント) を生成し、ブラウザに返す。
  6. Web ブラウザは、このアサーションを、経費精算ツール (SP) に対して自動的に送信する。
  7. SP は、IdP の公開鍵 (SP が信頼する鍵) を使用して、アサーションのデジタル署名を検証する。
  8. アサーションが有効な場合に、SP は経費精算ツール用のパスワードを要求することなく、ログインを許可する。つまり、SSO が実現したことになる。
SAML のユースケース

SAML は、以下のようなシナリオで威力を発揮する。

  • エンタープライズ SSO：各種の社内アプリやクラウド・アプリ (Microsoft 365／Google Workspace／Salesforce など) への、シームレスにアクセスを従業員に提供する。
  • フェデレーション ID：ある組織のユーザーが、所属組織の認証情報を使用して、別の組織のリソースにアクセスできるようにする。
  • 政府機関および教育機関：異なる機関や組織にまたがるユーザーを、安全に接続する。
SAML のメリットとデメリット

メリット：

  • 分離: Idp と SP を分離。
  • 成熟した標準：エンタープライズ環境で広範囲に採用。
  • Web SSO に強力: ブラウザ・ベースの SSO フロー向けの堅牢な設計。
  • セキュリティ: デジタル署名された XML アサーションを使用し、強力な整合性と認証保証を提供する。

デメリット:

  • XML の冗長性：JSON に比べてサイズが大きな XML は、解析が複雑になり得る。
  • ブラウザ中心：OAuth 2.0 と比べて、ネイティブ・モバイル・アプリや API セキュリティには本質的に適さない。
  • 複雑さ: SAML 統合の設定とトラブル・シューティングが複雑になり得る。

OAuth 2.0 を探る：認可フレームワーク

OAuth 2.0 とは？

OAuth 2.0 (Open Authorization) は、主に認可のために、特に委任アクセスのために設計されたオープンスタンダード・フレームワークである。ユーザーは、実際の認証情報を共有することなく、別のサービスでホストされているリソースへの限定的なアクセスを、サードパーティ・アプリケーションに許可する。

これは、車で乗り付けたホテルのボーイに、マスター・キー (実際のパスワード) ではなく、運転席のドアを開けてエンジンをかけるだけの、特別なキー (限定的な認可) を渡すようなものだ。つまり、特定の権限を委任することになる。この OAuth 2.0 Authorization Framework は、RFC 6749 で定義されている。

OAuth 2.0 の主な役割：

  • リソース所有者：Resource Owner：データ／リソースを所有するユーザー。
  • クライアント：Client：ユーザーのリソースへのアクセスを要求する、サードパーティ・アプリケーション (例：写真印刷アプリ)。
  • 認可サーバ：Authorization Server：リソース・オーナーを認証し、同意を得た後にアクセストークンを発行するサーバ (例：Google や Facebook の認可サーバ)。
  • リソース・サーバ：Resource Server：ユーザーの保護されたリソース (例：Google Photos API／Facebook Graph API) をホストするサーバ。

通常において、OAuth 2.0 ではアクセス・トークン (短命もしくは JSON Web Token の文字列) が用いられる。それを用いる Client が、ユーザーに代わって Resource Server へとリクエストを送信する。

OAuth 2.0 の仕組み：認可コード付与の簡略なフロー

例として、サードパーティ・アプリ (Client) を用いて、フィットネス・プラットフォーム (Resource Server) に保存されている、最近のアクティビティを分析したいとする。

  1. 分析アプリで、フィットネス・データへのアクセスを必要とするアクションを開始する。
  2. このアプリは、フィットネス・プラットフォームの Authorization Server へのリダイレクトを実行する。
  3. フィットネス・プラットフォームにログインすると、許可を求める画面が表示される。メッセージとして “分析アプリに対して、最近のアクティビティ・データへのアクセスを許可しますか？” が表示されるので、”Allow” をクリックする。
  4. Authorization Server は、あなたを分析アプリにリダイレクトし、一時的な認可コードを提供する。
  5. この分析アプリは、認可コードと Client 認証情報を、Authorization Server とダイレクトに交換し、アクセストークンを取得する。
  6. このアクセストークンを使用する分析アプリは、フィットネス・プラットフォームの API (Resource Server) に対して、アクティビティ・データを要求する。
  7. Resource Server はアクセストークンを検証し、それが有効であれば、要求されたデータを分析アプリに返す。
  8. この分析アプリは、フィットネス分析結果を表示する。ただし、フィットネス・プラットフォームのパスワードは、分析アプリと共有されない。
OAuth 2.0 のユースケース

OAuth 2.0 は、以下のような用途で広く使用されている。

  • ソーシャル・ログイン：よく見かける、”Google／Facebook／Twitter アカウントでログイン機能” では、基本的なプロフィール情報を取得するために、OAuth 2.0 が多用される。
  • API アクセス制御：サードパーティ・アプリによる、API 経由でのユーザー・データへのアクセスを安全に承認する 。たとえば、カレンダー・アプリをビデオ会議ツールに接続するケースなどがある。
  • モバイル・アプリ： バックエンド・サービスや API とインタラクションを、モバイル・アプリに対して承認する。
  • IoT：デバイスからの、クラウド・サービスへのアクセスを承認する。
OAuth 2.0 の長所と短所

メリット：

  • 最新の Web／モバイルに重点を置く：API／Mobile アプリを念頭に置いて設計されている。
  • 柔軟性：各種のクライアント・タイプ (Web アプリ／モバイルアプリ／サーバ) に適した、多様な “付与タイプ” (フロー) を提供する。
  • きめ細かな権限 (スコープ)：ユーザーが付与できるのは、all-or-nothing ではなく、特定された限定的な権限となる。
  • 広範な採用： API 認証におけるデファクト・スタンダードである。
  • ペイロードの軽量化: 多くのケースにおいて、XML よりも簡潔な JSON が使用される。

デメリット：

  • 認証ではなく認可：OAuth 2.0 自体は、ユーザーの認証方法を定義せず、アクセス権限の付与に重点を置いている。そのため、認証において OAuth 2.0 だけを使用すると、安全性の低下という問題が生じるかもしれない。
  • 複雑さ：付与の種類やセキュリティ上の考慮事項 (トークンの保存／転送など) 存在するため、慎重な実装が必要となる。ガイダンスについては、 OAuth 2.0 Security Best Current Practice などのリソースを参照してほしい。
  • ベアラー・トークンのリスク：標準アクセス・トークン (ベアラー・トークン) は現金のようなものであり、誰でも使用できるものであるため、安全な取り扱いと転送 (HTTPS) が必要となる。

SAML vs OAuth 2.0：直接比較

FeatureSAML 2.0OAuth 2.0
Primary PurposeAuthentication & SSOAuthorization (Delegated Access)
Protocol FormatXMLTypically JSON, Form-encoded
Key ArtifactSAML Assertion (contains identity info)Access Token (grants access, often opaque)
Main Use CaseEnterprise Web SSO, FederationAPI Authorization, Social Login, Mobile Apps
User InvolvementAuthenticates at IdP, transparent redirectsAuthenticates & Grants Consent at Authz Server
Mobile/API FitLess native fitDesigned with APIs/Mobile in mind
ComplexitySetup/Configuration can be complexImplementation security requires care, many flows
Standard BodyOASISIETF

最も重要なポイント：SAML の役割は、主にユーザーの身元を証明すること (認証) にあり、OAuth 2.0 の役割は、主にリソースへのアクセス権限を付与すること (許可) にある。

SSO において OAuth は SAML の代替になり得るか？

これは、百万ドルの価値のある質問だ！

それぞれの主目的に基づくと、OAuth 2.0 だけでは、従来の SSO における SAML の役割を完全に置き換えることはできない。OAuth 2.0 に欠けているのは、SSO コンテキストにおいて、各種のアプリケーション間で堅牢な認証を行うために必要な、詳細なユーザー ID 情報を伝達するための標準的な方法である。OAuth 2.0 は、アプリがアクセスできる情報を伝えるものであり、ログインに適した検証可能な方法で、ユーザーの身元を伝えるものではない。

しかし、ここで OpenID Connect (OIDC) が登場する。

OpenID Connect (OIDC) の登場

OpenID Connect (OIDC) は、OAuth 2.0 フレームワーク上に構築されたシンプルな ID レイヤーである。Authorization Server により実行される認証に基づき、Client によるエンド・ユーザー ID の検証を可能にしながら、その基本的なプロファイル情報も取得する。詳細については、OpenID Foundation の Web サイトを参照してほしい。

OIDC の本質は、OAuth 2.0 に欠けている認証要素の追加にある。ID トークンと呼ばれる、新しいタイプのトークンが導入され、通常では JSON Web Token (JWT) としてフォーマットされるという。この ID トークンには、Authorization Server (OpenID プロバイダとしても機能) により署名された、ユーザーの ID (ユーザー ID／名前／メールアドレスなど) に関する情報 (claim) と、認証イベント自体が含まれている。

OIDC + OAuth 2.0 と SAML の どちらを選ぶ？

OAuth 2.0 (認可フロー用) と OpenID Connect (ID トークン経由の ID 情報用) を組み合わせることで、SSO を実現するための強力なメカニズムが得られる。

OIDC／OAuth 2.0 は、現代的なアプローチであると考えられており、特にモバイル・アプリ／SPA (Single-Page Web Application)／API 駆動型エコシステムに適している。数多くのコンシューマ向けの “ソーシャル・ログイン” では、OIDC が使用されている。

SAML は、確立されたエンタープライズ環境において、既存のフェデレーションと Web ベース・アプリをサポートする強力な選択肢である。Okta や Auth0 (現在は Okta の一部) などのベンダーは、それらをサポートするソリューションを提供している。

SSO において、SAML と OIDC/OAuth のどちらを選択するのかは、多くの場合において、具体的なユースケース／関連するアプリのレガシー度／対象環境 (エンタープライズ vs. コンシューマ) により決まるだろう。

適切な標準の選択：意思決定

SAML もしくは OAuth 2.0 (+ OIDC) を選択する際には、以下の点に考慮してほしい。

  1. 主な目標：エンタープライズ・グレードの Web SSO が必要であれば SAML が有力候補となり、API アクセス制御と最新のアプリ／モバイル認証に重点を置くなら OAuth 2.0／OIDC が好まれるだろう。
  2. アプリケーション・ランドスケープ：従来からの Web アプリを統合しているなら、SAML の方が容易になるだろう。最新の SPA／Mobile／API を統合しているなら、OAuth 2.0／OIDC の方が適しているだろう。
  3. 環境：クローズドなエンタープライズ・エコシステムなら、SAML が一般的である。コンシューマ向けのシナリオなら、OAuth 2.0／OIDC が普及している。
  4. 既存のインフラ：アプリケーションと ID プロバイダは、どのような ID プロトコルをサポートしているのか？
  5. 開発者エクスペリエンス：新規の開発においては、XML ベースの SAML よりも、JSON ベースの OIDC／OAuth フローの方が扱いやすいと感じるかもしれない。

数多くの大規模な組織では、両方の標準が異なる目的で使用されている。既存のアプリにおける従業員の SSO には SAML が使用され、顧客向けのアプリ／モバイル・アプリ／社内 API のセキュリティ保護には、OAuth 2.0／OIDC が使用される。

結論：旅のまとめ

デジタル ID の世界を理解することは、複雑に思えるかもしれないが、SAML や OAuth 2.0 といった標準の、主目的を理解することは重要である。どちらか一方を選択するのではなく、特定のニーズと環境に基づいた、適切なツールの選択が重要となる。デジタル・インタラクションが進化を続ける中、セキュアでユーザー・フレンドリーなエクスペリエンスを構築するためには、SAML と OAuth 2.0 (+OIDC) の両方を、正しく理解することが重要となる。

前述のとおり、OAuth 2.0 自体は SSO 向けに設計されていないが、そこに OpenID Connect (OIDC) レイヤーを追加することで、SAML に代わって SSO を実現する、現代的でパワフルな選択肢となる。

ただし、その選択は、必ずしも置き換えを引き起こすものではない。特定のニーズと環境に基づいた、適切なツールの選択が重要である。SAML と OAuth 2.0／OIDC について理解していくことは、今後も重要であり続ける。

日常における認証／許可のエクスペリエンスを入口にして、SSO に関連する主要技術である SAML と OAuth 2.0 の違いと役割を、分かりやすく解説してくれる良記事ですね。　
SAML による “認証” と OAuth 2.0 は “認可” を丁寧に説明した後に、両者に適した使い道を明示しています。さらに OAuth に加わる OIDC (OpenID Connect) の役割も、全体的な文脈の中に位置づけてくれるので、この３つの位置関係がスッキリと整理されます。なんとなく、ぼんやりとしていた部分が、はっきりと見えてきます。よろしければ、Single Sign-On で検索も、ご参照ください。