OpenIDとSAMLの違いは何ですか？

OpenIDとSAMLの違いは何ですか？

オリジナルのOpenID 2.0とSAML

これらは2つの異なる認証プロトコルであり、技術レベルで異なります。

離れたところから、ユーザーが認証を開始すると違いが始まります。OpenIDでは、ユーザーログインは通常、認証を担当するリソースのHTTPアドレスです。一方、SAMLはサイトとIDプロバイダーの間の明示的な信頼に基づいているため、不明なサイトからの資格情報を受け入れることはかなり一般的ではありません。

OpenIDのIDは、ネット上を簡単に移動できます。開発者は、非常に異なるOpenIDプロバイダーのユーザーを受け入れることができます。一方、SAMLプロバイダーは通常、事前にコーディングする必要があり、選択したIDプロバイダーのみを使用してアプリケーションを統合します。受け入れられるOpenID IDプロバイダーのリストを絞り込むことは可能ですが、これは一般的なOpenIDの概念に反することになると思います。

OpenIDを使用すると、任意のサーバーからのIDを受け入れます。誰かがそうであると主張しますhttp://someopenid.provider.com/john.smith。これをデータベースのユーザーとどのように一致させますか？どういうわけか、たとえば、この情報を新しいアカウントに保存し、ユーザーがサイトに再度アクセスしたときにこれを認識します。ユーザーに関するその他の情報（名前や電子メールを含む）は信頼できないことに注意してください！

一方、アプリケーションとSAML Idプロバイダーの間に明示的な信頼がある場合、名前と電子メールを含むユーザーに関する完全な情報を取得でき、この情報は信頼関係のために信頼できます。つまり、IDプロバイダーが何らかの方法ですべての情報を検証し、アプリケーションレベルで信頼できると信じがちです。ユーザーが不明なプロバイダーによって発行されたSAMLトークンを持っている場合、アプリケーションは認証を拒否します。

OpenID ConnectとSAML

（セクションは07-2017を追加、08-2018を拡張）

この回答の日付は2011年で、その時点でOpenIDはOpenID 2.0を表していました。その後、2012年のどこかでOAuth2.0が公開され、2014年にはOpenID Connectが公開されました（詳細なタイムラインはこちら）。

最近これを読んでいる人にとって-OpenID Connectは元の回答が参照しているOpenIDと同じではなく、 OAuth2.0の拡張機能のセットです。

一方で、この答えは概念的な観点からいくつかの光を当てることができ、OAuth2.0の背景と今後の誰かのために非常に簡潔なバージョンでは、OpenIDの接続があることである事実OAuth2.0ではなく、それは標準的な方法追加のユーザー情報を照会するアクセストークンの後に、利用可能です。

元の質問を参照してください。OpenIDConnect（OAuth2.0）とSAMLの主な違いは、アプリケーションとIDプロバイダーの間で信頼関係がどのように構築されるかです。

• SAMLはデジタル署名に信頼関係を構築し、IDプロバイダーによって発行されたSAMLトークンは署名されたXMLであり、アプリケーションは署名自体とそれが提示する証明書を検証します。ユーザー情報は、特にSAMLトークンに含まれています。

• OAuth2は、アプリケーションからIDへの直接のHTTP呼び出しで信頼関係を構築します。リクエストには（プロトコルフロー中にアプリケーションによって取得された）アクセストークンが含まれ、レスポンスにはユーザーに関する情報が含まれます。

• OpenID Connectはこれをさらに拡張して、アプリケーションからIDプロバイダーへの呼び出しを伴うこの追加の手順なしで IDを取得できるようにします。このアイデアは、OpenID Connectプロバイダーが実際に2つのトークンを発行するという事実に基づいています。これは、access_tokenOAuth2.0が発行するものとまったく同じものと、IDプロバイダーによって署名されid_tokenたJWTトークンである新しいトークンです。アプリケーションはを使用して、JWTトークンに含まれるクレームに基づいてローカルセッションを確立できますが、を使用して他のサービスをさらにクエリすることはできません。id_tokenid_token access_token。OpenID ConnectはSAML2（署名済みトークン）とOAuth2（アクセストークン）のハイブリッドと考えることができます。

OpenIDとSAML2はどちらも、フェデレーションIDの同じ概念に基づいています。以下は、それらの違いの一部です。

1. SAML2はシングルサインアウトをサポートしていますが、OpenIDはサポートしていません
2. SAML2サービスプロバイダーはSAML2 IDプロバイダーと結合されますが、OpenID依存パーティはOpenIDプロバイダーと結合されません。OpenIDには、OpenIDが指定されると、対応するOpenIDプロバイダーを動的に検出する検出プロトコルがあります。SAMLには、アイデンティティプロバイダーディスカバリサービスプロトコルに基づくディスカバリプロトコルがあります。
3. SAML2を使用すると、ユーザーはSAML2 IdPに結合されます。SAML2識別子は、それを発行したSAML2 IdPに対してのみ有効です。ただし、OpenIDを使用すると、識別子を所有し、任意のOpenIDプロバイダーにマッピングできます。
4. SAML2にはさまざまなバインディングがありますが、OpenIDのバインディングはHTTPのみです。
5. SAML2は、サービスプロバイダー（SP）で開始することも、アイデンティティプロバイダー（IdP）で開始することもできます。しかし、OpenIDは常にSPを開始しました。
6. SAML 2はXMLに基づいていますが、OpenIDはそうではありません。
7. 過去3年間に開発されたアプリケーションのほとんどは、OpenID Connectのみをサポートしていました。
8. 2018年5月にMicrosoft Azure ADから渡された8B +認証リクエストの92％は、OpenID Connect対応のアプリケーションからのものでした。

技術的な詳細はさておき、パーティーにはかなり遅れましたが、SAMLと他の認証標準（OpenIDを含む）との最大の違いは、

SAMLは、アイデンティティプロバイダ（IDP）およびサービスプロバイダ（SP）が必要です手の前に、お互いを知るために事前に構成され、静的認証および承認を。OpenId（+ Connect）にはそのような要件はありません。

これは、誰がデータにアクセスしているかを完全に制御したいIDPにとって重要です。標準の一部は、特定のSPに提供されるものを構成することです。

たとえば、銀行は、事前定義されたサービスを除いて、ユーザーにサービスへのアクセスを望まない場合があります（規制またはその他の厳格なセキュリティルールのため）。

これは、OpenId IDPがそのような制限を強制できないことを意味するものではありません。OpenIDの実装者はアクセスを制御できますが、それはOpenIDの目的ではありません。

定義済みの厳密な静的なアクセス制御の違いを除いて、概念的に（技術的にではなく）、OpenID ConnectとSAMLは似ています。

結論として、SPの場合は、顧客が必要とするものをサポートする必要があります。

1. 顧客が個人のエンドユーザー顧客である場合（たとえば、Google IDを使用）、SAMLを忘れます。OpenID Connectを使用します。
2. 顧客が銀行の従業員にサービスを使用させ、サービスに提供するデータの静的リストのみをエクスポートしてもらいたい場合、銀行はおそらくSAMLのサポートを望んでいます。銀行にはクライアント制限付きのOpenID実装があるかもしれません。これはあなたのラッキーな日になります:)

SAMLとOpenIDはどちらもIDプロバイダー（略称IdP）、つまり分散型認証プロトコル（シングルサインオンID）として機能できます。

S ecurity A ssertion M ARKUP Lの anguage（SAMLは）セキュリティドメイン間認証および認可データを交換するためのプロファイルのセットです。SAMLドメインモデルでは、IDプロバイダーは特別なタイプの認証機関です。具体的には、SAML IDプロバイダーは、SAMLのSSOプロファイルとともに認証アサーションを発行するシステムエンティティです。これらの認証アサーションを使用する証明書利用者は、SAMLサービスプロバイダーと呼ばれます。ソース

O pen ID C onnect（OIDC）は、承認フレームワークであるOAuth 2.0上の認証レイヤーです。標準はOpenID Foundationによって制御されています。OAuthは、認証プロトコルおよび認証プロトコルとして特別に設計されたOpenIDではなく、認証プロトコル用です。OIDCは単純なJSON Web Token（JWT）を使用するため、JavaScriptを使用する方が簡単です。

ユースケースシナリオ：

ユーザーがFacebookまたはTwitterでログインしたいだけの場合は、OAuthを使用します。ユーザーが「自分のIDを他の人に所有させたくない」ため、ユーザーが独自のOpenIDプロバイダーを実行している首割りの場合は、OpenIDを使用します。

ソース