SAML と OAuth2 は、それぞれ異なる、しかし関連した目的のために設計された、オープン標準プロトコルです。主に SAML 2.0 は、ユーザーが本人であることを確認（authentication）し、ユーザー ID データをサービスに提供することを目的としています。OAuth 2.0 は、ユーザーが特定のリソースへのアクセスをサービスプロバイダーと共有することを認可する、承認のプロトコルとして設計されています。

SAML（セキュリティアサーションマークアップ言語）は、安定した基盤を持つセキュリティプロトコルで、ID データを共有するために企業や政府によって広く使われています。これらのデータは、XML データストラクチャを採用し、データ転送メカニズムにはシンプルな HTTP または SOAP を採用しています。サービスまたはリライングパーティー（RP）からリクエストがあると、ID プロバイダー（IdP）は、SAML を使ってユーザーデータ（ユーザ名、メールなどの属性） を提供します。

本人確認のトランザクションが行われる前に、リライングパーティー（RP）および ID プロバイダー（IdP）は、信頼関係を確立する必要があります。この関係性は、メタデータ、特定のエンドポイント、証明書への署名や暗号化、接続方法などいくつかのアーティファクトを交換することによって構築されます。

この関係性が築かれた後に、ウェブブラウザのセッション中に、ユーザーの ID を必要とする RP が IdP に対し、認証リクエストの付いたフォーム POST（またはリダイレクト）を送信します。すると、IdP は、インタラクティブログインでエンドユーザーの本人確認を行い、対応する ID データ（認証情報セット）をフォーム POST 経由で RPに返します。これらの ID データには、常に、 RP がユーザーを特定するために使用する識別子が含まれています。このやりとりの一環として、IdP は、他の RP からの認証リクエストがインタラクティブなログインをスキップできるよう、 シングルサインオン （SSO）セッションを設定することもできます。

RP が、追加の属性をリクエストする場合は、IdP に属性クエリを送信することで SSO セッションのコンテキスト内でリクエストすることができます。

通常、SAML レスポンスには、転送中のデータ操作が検出ができるよう、電子署名が付与されます。また、伝送路の暗号化（HTTPS）が不十分である場合は、暗号化される場合もあります。

2012年に初めてリリースされた OAuth 2.0は、OAuth2としても知られており、サービスプロバイダーにホストされているリソースに、ユーザーが認証情報を提供しなくてもアクセスできるようにする認可（権限付与）プロトコルです。ユーザーのリソースの特性は、プロトコル仕様には定義されていないため、データまたはその他のエンティティとなる可能性があります。OAuth2 は、幅広いデバイスとアプリケーションから使用できる豊富な機能を備えています。また、OAuth2 は、よく使われている認証プロトコル OpenID Connect を基盤として構築されています。

OAuth2 の用語では、ユーザーのリソースへのアクセスを要求するサービスはクライアント、これらのリソースを供給するサービスをリソースサーバーです。リソースサーバーが保持しているユーザーリソースへのアクセスは、アクセストークンアーティファクト（アクセス認可を証明するアーティファクト）の使用により制御されています。さらに、OAuth2 は、スコープと名付けられたメカニズムを提供しています。これは、ユーザーのリソースに関する許可を制限するものです。

ユーザーを認証し、最終的にアクセストークンで返答するシステムは、認可サーバーです。

OAuth2 が使われるようになるまでは、SAML のように、クライアントとリソースサーバーは、認可サーバーによって一部のデータを交換する必要がありました。少なくとも、認可サーバーからクライアント ID とクライアントシークレットを取得し、コールするエンドポイントに合意し、特定情報を取得します。

OAuth2 は、大変柔軟性に優れているため、多数の、グラントとして知られているフローをクライアントに提供し、アクセストークンを取得します。どのグラントを使うか は、ほとんどの場合、クライアントタイプ（モバイルアプリ、ネイティブアプリ、ウェブクライアントなど）と全体的なセキュリティ要件に依ります。おそらく最も一般的なものは、認証コードグラントで、これは、ユーザーリソースへのアクセスが必要なクライアントアプリケーションが、通常のウェブアプリのときに適用されます。次に、このグラントにおけるクライアント、リソースサーバー、そして認可サーバーのインタラクションついて簡単に説明します。

1.クライアントが、ユーザーを認可サーバーにリダイレクトすると、認可サーバーは特定スコープでユーザーリソースへのアクセス権限をリクエストします。

2.認可サーバーは、特定のスコープに権限を付与することを承認したユーザーと、インタラクティブログインを実施します。

3.認可サーバーは、シングルユース認証コードを使って、ユーザーをクライアントのエンドポイントにリダイレクトします。

4.クライアントは、認可サーバーと認証を行い、認可コードを交換し、アクセストークンを取得します。

5.アクセストークンを使って、クライアントは、リソースサーバーからのユーザーのリソースを要求します。

SAML は、シングルサインオンにも対応していますが、属性クエリによる認可にも対応しています。OAuth は、「Facebook アカウントでサインイン」などのソーシャルログインを使用する際に、認証（本人確認）の役割を強いられることがよくありますが、あくまでも認可に重きを置いています。それにもかかわらず、OAuth2 は、SSO には対応していません。

技術的な観点から言うと、SAML はトークン形式を定義し、その暗号化は複雑で、交換されるメッセージは大規模です。反対に、OAuth2 は、メッセージの暗号化はまったく行わず（HTTPSに依存）、トークン形式も定義しません。

OAuth2 の魅力は、その使いやすさと柔軟性です。モバイルデバイス、スマートデバイス（例：スマートＴＶ）、ウェブアプリ、シングルページアプリなどで使うことができます。多数のライブラリも用意されているため、あらゆるクライアントタイプやサービスプロバイダーとの統合プロセスを簡易化できます。反対に、SAML は、これらの新しい用途については考慮して設計されていないため、このようなシステムでの利用は難しくなります。従来のウェブアプリで一般的に利用されています。

SAML は、よく政府や企業のアプリケーション（ID 管理）のSSO に使用されており、XML 形式のバックエンドシステム処理が一般的です。政府による多数の国民 ID 計画（例：UK Verify）は、SAML をベースにしています。

OAuth2は、認証および認可の両方の役割で、消費者や企業のアプリケーションに広く利用されています。一般的に、アクセストークンを利用することでシンプルかつ魅力的なものとなっている RESTful API へのアクセスの認可に使われています。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。