SAML (SAML 1.0 and 2.0) および OpenID Connect (OIDC) は、ユーザー ID のための通信方法として、ユーザーを認証し、アクセス管理用の ID データを提供することを目的とした ID プロトコルです。いずれも幅広いユーザー ID 管理とサービスを提供する ID プロバイダー（IdP）の基盤として、シングルサインオン（SSO）アプリケーションに使われます。

主に企業や政府のアプリケーションに使用されている SAML 2.0は、2005年以来、幅広い ID 機能に対応している成熟したテクノロジーです。SAML は、ID データ形式に XML 、そして、データ転送メカニズムには、シンプルな HTTP または SOAP を採用しています。IdP からデータを要求し、受信するサービスは、リライングパーティー（RP）として知られています。ユーザー ID データ（メールアドレス、ユーザー名、電話番号など）は、属性として記述され、SAML アサーションと呼ばれる XML 文書にカプセル化されます。

SAML は、フェデレーション ID のメカニズムを提供することができます。

サービスプロバイダー/リライングパーティーは、ユーザー認証について IdP とやりとりを行います。RP と IdP の間ではメタデータが交換されなければいけません。XML 形式のこれらのメタデータは、エンドポイント、署名証明書や暗号化証明書、対応接続方法、属性形式などを特定します。SAML バイナリーの双方が互いを認識する必要があります。各当事者が、相手側のメタデータを使い、システムの自分側を設定します。

ユーザーを認証するため、RP は、IdP に認証リクエスト（SAML AuthnRequest）を行い、HTTP POST (POSTバインディング）またはクエリ文字列によるリダイレクト(リダイレクトバインディング）のいずれかを使って、リクエストを行います。このリクエストは、通常、RP が署名します。

その後、IdP がリクエストを検証し、ユーザーを認証した後、SAML レスポンスを POST 形式で RP に戻します。このSAML レスポンスには、合意済みの属性が付いた SAML アサーションが含まれています。中には、属性の開示に関するユーザーの同意に対応している IdP もありますが、SAML プロトコルには含まれてはいません。普通、SAML レスポンスおよびアサーションは、IdPによってデジタル署名が行われます。アプリケーションが HTTPS は十分に安全ではないと判断した場合には、アサーションは、暗号化される場合があります。

SAML は、条件を満たしたユーザーの認証方法、SSOの無効化（IdP への強制ログイン）、プロキシ― IdP の制限などの動的挙動を可能にする幅広い AuthnRequest オプションに対応します。他にも対応するカスタムオプションがあります。

比較的新しいプロトコルである継続的に変化し続ける OIDC は、ウェブおよびモバイルアプリケーションを対象としています。導入しやすく使いやすい OIDC は、OAuth2 の拡張子です。JSON 形式（JWT）のデータ構造を持ち、転送にはシンプルな HTTPS フローを用います。ユーザー ID データ（「クレーム」）は、JSON ウェブトークン（ID トークン）で発行されます。クレームには、リクエストされたスコープによって定義された、関連する識別子とユーザーデータが含まれます。元々、このトークンはデジタル署名されており、必要に応じて暗号化される可能性もあります。

OIDC scopes は、IdP が、どのクレームまたはクレームグループを戻すのかを特定するために使われます。許容されるスコープ値、どのクレームが正確に関連しているのかは、そのIdP によります。多数の一般的なスコープとクレーム（プロファイル、アドレス、メールなど）が、OIDC にて定義されます。

たとえば、スコーププロファイルには、通常、ユーザー名が含まれますが、IdP がどのようなデータを持っているか、定義する内容を含めるべきなのかによって、写真、生年月日、その他の個人データが含まれる可能性があります。

SAMLのように、OIDC が使われるようになる以前RP と IdP は、データをお互いに交換しなけれなりませんでした。しかしOIDC では、このようなデータはかなり単純化されています。少なくとも、RP は、クライアント ID及びIdP の秘密事項を取得し、潜在的なスコープに合意し、そしてURL エンドポイントの IdP にコードまたはトークンを戻すよう通知します。

OAuth 2.0 に基づいた OIDC には、どのように RP と IdP がやり取りを行うか正確に決定する、フローと呼ばれる多数のユースケースがあります。最もシンプルなフローは、RP がクライアント ID と必要なスコープ値とともに、 IdP にリダイレクトする暗黙的な許可のフローです。ユーザーがこれらのデータを認証し、合意した後、IdP は、RP のプリセットエンドポイントにリダイレクトすることで、 ID トークンにあるクレームを戻します。 安全性の高いフローは、直接 ID トークンの送信に関与することはありませんが、RP がバックエンド POST を介してトークンの交換をする、シングルユースコードを返します。ID トークンに加え、アクセストークンも発行される場合があります。その場合、アクセストークンは、スコープに含まれるユーザーリソースへのリクエストを認可するため、RPによって使用されます。

SAML は、長い年月にわたり、ID データ交換の安全な手段を提供し続け、多数の企業から信頼されています。また、豊富な機能であらゆる ID 要件に対応しています。

OIDC はSAMLより新しく、しかも進化し続けているものの（特に欧州の銀行部門、オープンバンキング） 、機能の点では今でもSAML に遅れを取っています。たとえば、プロキシー IdP の動的仕様は、未だに完全に対応していません。しかし、基本的な ID データで要件も複雑でない多数のアプリケーションに関しては、OIDC は SAML よりかなり使いやすく、SAML ほど負荷 XML の取り扱い を求めないため、特に消費者向け分野にとっては大変魅力的です。

現在、SAML は政府の国民 ID や企業の認証に広く使われています。ただし、SAML の代わりに OIDC を必要とするより新しいシステムが増えるにつれ、この状況は変わり始めています。XML ではなく、JSON（IDトークン）を使った、OIDC のデータ処理要件は、スピーディーで負荷がかからないと考えられているからです。OIDC は、SAMLの使用が難しい、モバイルアプリやシングルページのウェブアプリへの利用に最適です。

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