SAMLとOAuthを使用したフェデレーションログイン
回答:
彼らはさまざまな問題を解決します。
SAMLは、ユーザーが誰であるか、ユーザーの属性は何かに関する情報を共有し、何かへのアクセスを許可/拒否したり、認証を要求したりできるようにするために定義された標準のセットです。
OAuthは、何かへのアクセスの委任に関するものです。あなたは基本的に誰かがあなたのように「行動する」ことを許可しています。これは、ユーザーに代わって何かを実行できるアクセスAPIを付与するために最も一般的に使用されます。
それらは2つのまったく異なるものです。
役立つかもしれないいくつかの例。
OAuthはTwitterを思い浮かべます。GoogleバズとTwitter を使用していて、2つを同期し続けることができるアプリを作成したいとします。基本的に、アプリとTwitterの間で信頼を確立できます。初めてアプリをTwitterにリンクするときは、クラシックプロンプトでTwitterにログインすると、確認ボックスがポップアップし、「«アプリ名»へのアクセスを許可しますか？」「はい」をクリックすると、信頼が確立され、アプリがTwitterであなたと同じように動作できるようになります。投稿を読んだり、新しい投稿を作成したりできます。
SAML-SAMLの場合、2つの無関係なメンバーシップシステム間のある種の「合意」について考えます。私たちのケースでは、US AirwaysとHertzを使用できます。あるサイトから別のサイトに移動できる共有の資格情報のセットはありませんが、ハーツがUSエアウェイズに「取引」を提供したいとします。（私はこれが極端な例であることを承知していますが、我慢してください）。フライトを購入すると、会長会員に無料のレンタカーを提供します。USエアウェイズとハーツは、何らかの形で信頼を確立し、ユーザーを特定する方法を確立しました。私たちの場合、「フェデレーテッドID」は電子メールアドレスであり、これはHertzがUS Airways IDプロバイダーが正確で安全な方法でトークンを配信することを信頼する1つの方法セットです。フライトを予約した後、USエアウェイズのIDプロバイダーはトークンを生成し、ユーザーの認証方法を入力します。この場合、個人に関する「属性」に最も重要な属性はUSエアウェイズのステータスレベルです。トークンが入力されると、トークンは何らかのタイプの参照を介して渡されるか、URLにエンコードされ、Hertzに到達すると、トークンを確認して検証し、無料のレンタカーを利用できるようになります。
このSAMLの例の問題は、多くの特殊なユースケースの1つにすぎないことです。SAMLは標準であり、実装する方法が多すぎます。
または、承認を気にしない場合は、SAMLおよびOpenIDを介して認証をアサートすることをほぼ主張できます。
ここに要約されているこの簡単な説明を見てください：
多くの人々はSAML、OpenID、OAuthの違いについて混乱していますが、実際には非常に簡単です。いくつかの重複がありますが、ここでは3つを区別する非常に簡単な方法を示します。
OpenID –消費者向けのシングルサインオン
SAML –エンタープライズユーザー向けのシングルサインオン
OAuth –アプリケーション間のAPI認証
OOのデザインパターンに慣れている人のために、ラッパーパターンには素晴らしい結果があると思います。Facade、Decorator、Proxyのパターンを考えてみてください。基本的にこれらはすべて同じで、単なるラッパーです... 違いは、各パターンの意図です。
同様に、SAML、OAuth、OpenIDはすべて、共通の基礎となるメカニズムを介してさまざまな意図を促進します。これは、プライベートインタラクションのためにサービスプロバイダー/ ID機関にリダイレクトされ、その後、元のサードパーティアプリにリダイレクトされます。
ネットを見回すと、プロトコルの機能が重複しています。OAuthによる認証は完全に合理的です。SAMLとOpenIDはフェデレーションIDに特化しているため、OAuth経由のSSOはあまり意味がありません。
問題自体、企業のコンテキストでは、SAMLはOAuth for SSOよりも適切に聞こえます。企業IDと統合したいサードパーティのアプリを見ると、SAML / LDAP / Radiusなどと統合するようにすでに設計されていることに気付くでしょう。インターネットの相互作用にはIMO OAuthがより適切です。アプリケーション間、またはおそらく大規模な企業環境でサービス指向アーキテクチャを構成するアプリケーション間。
承認規則は、他の方法でも企業環境で指定できます。LDAPはこのための一般的なツールです。ユーザーをグループに編成し、アプリケーション権限をグループメンバーシップに関連付けることは、広く行われているアプローチです。LDAPは認証にも使用できます。Active Directoryは良い例ですが、私はOpenLDAPを好みます。
SAML（セキュリティアサーションマークアップ言語）は、シングルサインオン（SSO）、フェデレーション、ID管理を実現するための標準のセットです。
例：ユーザー（プリンシパル）が、フライト予約WebサイトAirFlyer（IDプロバイダー）で認証します。これは、シャトル予約Webサイト、Shuttler（サービスプロバイダー）を使用してSAML経由でSSOが構成されています。フライヤーに認証されると、ユーザーは認証を要求せずにシャトルでシャトルを予約できます
OAuth（Open Authorization）は、リソースの承認の標準です。認証は扱いません。
例：ユーザーがInstagramアカウント（OAuthプロバイダー）から写真をインポートできる写真共有モバイルアプリ（OAuthコンシューマー）。一時的なアクセストークンまたはキーを写真共有アプリに送信し、数時間後に期限切れになります。
SAMLには、他のユーザーがサイトに「ログイン」できるようにするさまざまな「プロファイル」があります。SAML-PまたはSAMLパッシブは非常に一般的で、設定はかなり簡単です。WS-Trustも同様で、Webサイト間のフェデレーションも可能です。
OAuthは認証用に設計されています。あなたはここでもっと読むことができます：
SAML認証用-主にシングルサインオンシナリオで使用されます。OAuthリソース表現の承認用です。
JSON Web Token（JWT）は、SAML XMLトークンの代替手段です。JWTはOAuthで使用できます
良いリファレンスはSAMLとOAuthです。どちらを使用すればよいですか。
フェデレーションという用語は、実際にはシステム全体の接続IDを意味します。これはSSOに関連していますが、まったく同じではありません。このブログの投稿は、フェデレーションが実際に何を意味するかという点で非常に役立ちました。