web-dev-qa-db-ja.com

JSON Web Token、SAML、OAuth 2の違いは何ですか？

JSON Webトークン、SAML、およびOAuth 2.の違いは何ですか。2。いくつかのポインタとそれらの機能の概要を提供してください。

具体的には、なぜJSON Webトークンを介してSAMLを使用するのか、またはその逆の理由ですか？ JSON Web Tokens/SAMLを使用するにはOAuth 2が必要ですか？それともJSON Web Tokens/SAMLを個別に使用できますか？

authenticationjwtoauth2saml
24
Jadiel de Armas

SAMLおよびOAuth 2は、認証/承認で使用されるプロトコルです。JSONWeb Tokens（JWT）は、多くのアプリケーションまたはプロトコルで使用できるトークンの仕様です-OpenID Connect（ OIDC）プロトコルはJWTを使用します。SAMLは独自のトークンも定義します：SAMLアサーション;同様にOAuth 2：アクセストークン。これらのプロトコルで使用されるトークンは、認証/承認されたことを示し、あなたまたはセッション。

+----------+----------------+-------------------------------+
| Protocol | Token          | Technologies | Design Pattern |
+==========+================+==============+================+
| SAML     | SAML Assertion | SOAP, XML    | Facade         |
+----------+----------------+--------------+----------------+
| OAuth 2  | Access Token   |              | Proxy          |
+----------+----------------+--------------+----------------+
| OIDC     | Access Token,  | REST, JSON   | Decorator      |
|          | ID Token (JWT) |              |                |
+----------+----------------+--------------+----------------+

上記の表の各プロトコルに関連するソフトウェア設計パターンは、これらのプロトコルが達成することを意図したものを1つの単語で要約しています。

[〜＃〜] saml [〜＃〜]。 Facadeパターンは、サブシステム内の一連のインターフェースに統合インターフェースを提供します。 SAMLは、学生が他の大学図書館にアクセスできるようにするために大学が発明した元の統合IDシステムですが、各大学は独自の学生IDシステムを維持しています。ほとんどのエンタープライズ環境での事実上の標準。 XMLとSOAPを中心に構築されています。

OAuth 2。プロキシは、その名前が示唆しているように、クライアントがあなたのプロキシであるかのようにあなたの情報にアクセスすることをクライアントに許可します。

[〜＃〜] oidc [〜＃〜]。プロトコルにユーザーIDとユーザー情報を追加することにより、OAuth 2を拡張します。多くの場合、最新バージョンのSAMLと見なされます。コンシューマースペースで広く使用されています-ほとんどすべてのソーシャルメディアサイトがOIDCをサポートしています。JSONを中心に構築残りの部分。

うまくいけば、これはあなたの質問を少し解きほぐします。 SAML（プロトコル）とJWT（トークン）を完全に比較することはできませんが、SAMLとOIDCを比較することはできます。ただし、SAMLアサーションとOIDC JWTを比較することはできます。 OAuth 2の仕様では、トークンの基本的な構造を指定していません。OIDCがSAMLアサーションと独自のJWTを消費できることも興味深いかもしれません。

OIDCは最終的にSAMLに取って代わるというコンセンサスはありますが、SAMLは2005年から存在し、非常に成熟しています。これはエンタープライズ環境での重要な特性です。 OIDCは比較的新しい（2014年）ですが、最近（2018年）の認証ソリューションはそれをサポートすることが期待されています。 SAMLは、Webブラウザーが主流であった時代に設計されており、モバイルアプリケーションや最新のWebアプリケーションを使用するのは少し面倒です。一方、OIDCはRESTやJSONのような最新のテクノロジーをサポートしているため、最近のアプリケーションからアクセスしやすくなっています。

ただし、OAuth 2、OIDCおよびSAMLは、これら2つの用語が従来定義されている方法での認証と承認の方法を実際に指定していません。

認証を聞くと、ログイン/パスワード、指紋、または電話に送信されたパスコードを思い浮かべます。これらのプロトコルはこれらの詳細をカバーしておらず、認証はアイデンティティプロバイダー（IdP）に委任されています。これらのプロトコルは、認証を受けるためにIdPにリダイレクトする方法と、成功した場合にトークン/アサーションが返される方法を指定します。

OAuth 2の "承認"は、ユーザーの同意の取得を扱います。つまり、サービスに情報/データへのアクセス権を与えるかどうか-これはアクセス制御感覚。 OAuth 2とよく似たOIDCは、ユーザーの同意を取得する手段もサポートします。SAMLはユーザーの同意もサポートしますが、通常、エンタープライズ/イントラネット環境では使用されません。

承認（より伝統的なアクセス制御の意味を参照）もOAuth 2、OIDCおよびSAML仕様に含まれていませんが、トークンに、ユーザーが管理者グループに属しているかどうかなどのクレームを含めることができます、どのクライアントサービスでも好きなように解釈できます。

OAuth 2、OIDC、およびSAMLは、さまざまな認証および承認（アクセス制御）スキームの優れたファシリテーターですが、実際に実際の基礎となるメカニズムを指定していません。

2018年9月5日更新。 2018年に更新されました。

2017年4月26日更新。 SAMLがユーザーの同意をサポートしていないという誤った記述を修正しました。サポートはしていますが、広く使用されていません。

2017年2月22日更新。以下のユーザーコメントに応じて、認証、承認（アクセス制御）、およびユーザーの同意を明確にします。

25
HTLee