SAML vs OAuth：主な違いと代表的なユースケース

はじめに：役立つたとえ話

SAML と OAuth の根本的な違いは、両者が使うトークンの性質にあります。SAML は、大きくて公式っぽい見た目の XML トークンを渡します。押印され、公証されたかのようで、書類の匂いがします。これに対して OAuth は、代わりに小さな JWT トークンを投げ渡して、「ほら、これで数時間だけ VIP セクションに入れます。なくさないでね」と言うようなものです。

この違いをイメージしやすくする、便利な例えがあります。SAML は、招待制の特別なパーティーに行くようなものです。自分がそもそも入れてもらえるのか不安になります。ありがたいことに、あなたの友人が入口に来て、「この人は私と一緒です。いい人です」と言ってくれるので、ホストは質問なしであなたを入れてくれ、好きなだけ滞在できます。

OAuth は、誰かがあなたに自分の車を貸してくれるのに近いです。相手はあなたに家へのアクセスや銀行口座や自転車へのアクセスは渡しません。渡すのは“車だけ”です。同様に、OAuth はあなたの情報をすべて渡すことなく、特定のことを実行できるように認可します。たとえば「Facebookでログイン」や「Googleでログイン」をクリックするときに、そうした仕組みを見たことがあるはずです。Facebook や Google は、アクセスしたいアプリに対して、名前やメールアドレスのように仕事を進めるのに十分な情報だけを渡し、あなたの人生全ての物語は渡しません。特に OAuth は、アプリにあなたのパスワードを共有しません。代わりに、「この人は X、Y、Z を行うことが許可されています」という内容の特別な Web トークンを渡します。

さらに深掘り：SAML（Security Assertion Markup Language）

SAML は、パーティーに入れるように友人があなたを保証してくれるのに似ている、と話しましたね。SAML では、パーティーへの入場ではなく、アプリケーションやサービスへのアクセスを要求します。そしてその“友人”にあたるのがアイデンティティプロバイダー（identity provider）です（Google のようなもの、または会社の社内システム）。アイデンティティプロバイダーは、サービス側に対して「すでにあなたを認証したので、サービスはアクセス要求を許可すべきだ」と伝えます。

主なユースケース

SAML の主な利点は、シングル サインオン（SSO）を可能にすることです。ユーザーは 1 回認証するだけで、その後は再度サインインしたり別アカウントを使ったりすることなく、複数のシステムにアクセスできます。

そのため、SAML は SSO が不可欠な環境に最適です。たとえば教育、医療、政府分野の企業などが該当します。異なるドメインにまたがる複数のアプリケーションでユーザーを管理しており、ユーザーに複数回のログインを強いることなく認証を簡素化したい場合、SAML は最適なプロトコルです。

SAML の仕組み

SAML には 3 つの主要コンポーネントがあります。

• ユーザー — アクセス権を得ようとしている人
• サービスプロバイダー — ユーザーがアクセスしたいアプリケーションまたはサービスの提供先
• アイデンティティプロバイダー — ユーザーを認証する主体

これらのコンポーネントは、次のように連携します。

1. ユーザーがアプリケーションまたはサービスにアクセスしようとします。
2. サービスプロバイダーは、認証のためにユーザーをアイデンティティプロバイダーへリダイレクトします。
3. アイデンティティプロバイダーは、ユーザーがすでに認証済みであることを確認し（未認証の場合は認証手順を実行し）、ユーザーを証明する XML トークンを返します。
4. サービスプロバイダーは XML トークンに基づいて、ユーザーにアプリまたはサービスへのアクセスを許可します。

SAML の主な機能

• フェデレーション・アイデンティティ — アイデンティティを異なるドメイン間で共有できるようにします
• SSO — 異なるシステム間でシームレスな認証を可能にします
• エンタープライズでの利用 — 主に B2B 環境で使用されます。社内および第三者アプリケーション間で安全にアイデンティティを共有することが重要な場合に適しています
• XML ベース — 当事者間の通信に XML を大きく依存しています

SAML を使用する利点

• アカウント侵害のリスク低減 — ユーザーは 1 セットの認証情報だけで済むため、強固なパスワードを選びやすく、書き留めるなどの危険な回避策に頼らずに覚えられる可能性が高くなります。
• IT の運用負荷を削減 — ログインに関するパスワードのリセットやサポートチケットが減ることで、ユーザーと IT スタッフの双方の時間を節約できます。
• パスワード窃取のリスクを低減 — パスワードはユーザーとサービス提供者の間で送信されません。

より深く掘り下げ：OAuth

OAuth は、友だちが自分の車は使っていいと言ってくれるけれど、他の持ち物は一切渡さないようなものだと説明しました。同様に OAuth は、あなたのパスワードを共有することなく、限られた範囲のアクセス許可を認可します。たとえば OAuth によって、第三者のアプリや Web サイトにあなたの Facebook の写真へのアクセスを許可できます。その際、あなたのログイン資格情報を含め、Facebook があなたに関して保存している他の情報は一切公開されません。

OAuth の仕組み

OAuth の主要な構成要素は次のとおりです：

• クライアント — ユーザーに代わって、リソースへのアクセスを要求するアプリケーション
• リソース所有者 — 要求されているデータまたはアプリケーションを所有し、それへのアクセスを許可できるユーザーまたはシステム
• 認可サーバー — ユーザーの同意後にトークンを発行するサーバー
• リソースサーバー — リソースを保存している API またはサービス

プロセスは以下のとおりです：

1. ユーザーは、リソース所有者が保持している自分に関する特定のデータへのアクセスを、クライアントアプリケーションに許可したいと考えます。
2. クライアントが、適切な認可サーバーに認可を要求します。
3. 認可サーバーはクライアントを認証し、リソース所有者からアクセスの同意を得たうえで、アクセス トークンをクライアントに送信します。
4. クライアントはアクセス トークンを使って、リソース サーバーに対して目的のリソースへのアクセスを要求します。

OAuth のユースケース

OAuth は、一般ユーザー向けのアプリケーションや、サードパーティのアプリがユーザーデータに対して限定的なアクセスを必要とする状況に最適です。たとえば、外部 API からデータにアクセスする必要があるモバイルアプリを構築している場合、OAuth はユーザーの資格情報を損なうことなく、そのアクセスを許可するための安全で標準化された方法を提供します。

OAuth の主な機能

• 認可（Authorization）に重点を置いている — 資格情報を共有せずにサードパーティがリソースへアクセスできるように設計されている
• API を中心に設計されている — モバイル、Web、クラウドのアプリケーションにおいて、特に API へのアクセスを保護するために広く使用されている
• トークンベース —アクセス トークン（通常は JSON 形式）を使用して、アクセスを許可または拒否します
• 消費者向け —Facebook や Google のような B2C アプリケーションでよく使われます。

OAuth を使用する利点

• 侵害リスクの低減 — OAuth は、一定期間だけ特定のリソースへのアクセスを許可するトークンを使用します。
• 柔軟性 — OAuth は、モバイル デバイス、デスクトップ、Web ブラウザ、IoT デバイスで使用できます。
• 顧客満足度の向上 — 組織は、Google や Facebook などの信頼できる第三者の認可システムを利用して、自社のリソースへのアクセスを許可し、顧客体験を簡素化できます。

比較分析：SAML と OAuth

SAML と OAuth の共通点

• OAuth と SAML の両方により、シングルサインオンが可能になり、ユーザーは一度認証するだけで複数のサービスにアクセスできます。
• 両方のプロトコルにより、複数のシステム、アプリケーション、または組織間でアイデンティティ情報を共有できます。
• 両方のプロトコルは、第三者サービスと認証情報を共有または保存する必要をなくすことで、ユーザーの利便性とセキュリティを高めます。

SAML と OAuth の違い

• OAuth は軽量な JSON ベースのトークンを使用するのに対し、SAML は冗長な XML ベースのトークンを使用します。
• OAuth は一般的に消費者向けの Web やモバイルアプリで使用されるのに対し、SAML は主に企業レベルの SSO（シングルサインオン）とアイデンティティフェデレーションに使用されます。
• OAuth のトークンは API へのアクセスを認可するために使用されますが、SAML のアサーションはシステム間の認証を確立するために使用されます。

並べて比較

プロトコルの共存

SAML と OAuth は、認証と認可の両方が必要なシステムで連携して動作できます。たとえば、従業員が SAML を使って社内システムにログインしたあと、システムが OAuth のアクセス トークンを発行して、Microsoft Graph や Google Drive のような外部サービスや API とやり取りできるようにすることがあります。

セキュリティ上の懸念とベストプラクティス

トークンの盗難とリプレイ攻撃

OAuthトークンは通常有効期間が長いため、悪意のある攻撃者により奪取されるリスクがあります。攻撃者はそれを使って重要なデータやシステムにアクセスできます。たとえば、OAuthトークンはMan-in-the-Middle攻撃のような手法で傍受されたり、十分に保護されていないストレージから盗まれたりする可能性があります。

これらのリスクを最小限にするために、組織は有効期限の短いアクセス・トークンを使用し、常にTLS暗号化を提供するHTTPSを使用できます。

XML Signature Wrapping

XML署名とは、SAMLトークンのようなXMLドキュメントに付加されるデジタル署名です。有効な署名は、そのドキュメントが信頼できる発行元から来ており、改ざんされていないことを示します。攻撃者は、有効な署名を維持したままSAMLトークンに悪意のあるデータを注入することで、この検証メカニズムを悪用できます。

これらの攻撃に対抗するには、組織は強力なデジタル署名を要求し、SAMLトークンを暗号化して、その完全性と機密性を保護できます。

今後のトレンドと展開

組織は、従来の「パスワードのみ」による認証から急速に離れ、マルチファクター認証（MFA）や、passkeys のようなパスワードレスの選択肢を採用し始めています。さらに広く言えば、Zero Trust のセキュリティモデルを導入しており、「決して信頼せず、常に確認する」ことの重要性を強調しています。加えて、脅威検知能力を高めるために人工知能（AI）や機械学習（ML）を取り入れています。

まとめ

SAML と OAuth はどちらも、アプリケーションやデータへのアクセスを管理するうえで重要な役割を果たしますが、取り組む課題は異なります。SAML はユーザーの本人確認に重点を置き、企業環境での SSO（シングルサインオン）に一般的に使用されます。一方 OAuth は、Web やモバイルアプリケーションにおいて API やリソースへ安全にアクセスするための、きめ細かなパスワードレス権限付与を目的として設計されています。両方のプロトコルにより、強固なセキュリティを維持しながら、よりスムーズでシンプルなユーザー体験を実現する取り組みを支援できます。