私はJWTを使用したステートレス認証モデルを持つ新しいSPAを持っています。私はよく、単純なトークンヘッダーの代わりにリクエストごとに 'Bearer tokens' を送信するよう求めるなど、認証フローにOAuthを参照するよう求められますが、OAuthは単純なJWTベースの認証よりはるかに複雑だと思います。JWT認証をOAuthのように動作させる必要があるのでしょうか?
また、XSRF対策としてJWTをXSRF-TOKENにしているのですが、「別々にしてください」と言われています?別々にしたほうがいいのでしょうか?コミュニティーのガイドラインにつながるかもしれませんので、ご協力をお願いします。
TL;DR 一方、多くの異なるクライアント(ブラウザベース、ネイティブモバイル、サーバーサイドなど)がある場合、OAuth 2.0のルールに従うことで、独自のシステムを構築するよりも管理しやすくなるかもしれませんね。
別の回答で述べたように、JWT(Learn JSON Web Tokens)は単なるトークン形式であり、デジタル署名されているため検証・信頼できる方法で当事者間でデータを伝送するためのコンパクトで自己完結したメカニズムを定義しています。さらに、JWTの符号化規則により、これらのトークンはHTTPのコンテキスト内で非常に使いやすくなっています。
トークンは自己完結型であるため、ステートレス認証機構(別名:Look mum, no sessions!)を実装するのにも適しています。このように、保護されたリソースへのアクセスを許可するために当事者が提示しなければならない唯一のものは、トークンそのものである場合、問題のトークンはベアラートークンと呼ばれることがあります。
実際には、あなたがやっていることは、すでにベアラートークンに基づくものとして分類することができます。しかし、OAuth 2.0 関連の仕様 (RFC 6750 を参照) で規定されているようにベアラートークンを使用していないことを考慮してください。つまり、Authorization
HTTP ヘッダーに依存し、Bearer
認証スキームを使用していることになります。
CSRFを防ぐためにJWTを使用することについては、正確な詳細を知らないので、その実践の妥当性を確認することは困難ですが、正直なところ、それは正しくなく、価値があるとは思えません。この件に関しては、以下の記事(Cookies vs Tokens: The Definitive Guide)が役に立つかもしれません、特にXSS and XSRF Protectionのセクションです。
最後のアドバイスとして、OAuth 2.0に準拠する必要がない場合でも、カスタムヘッダを使用する代わりに Authorization
ヘッダにアクセストークンを渡すことを強くお勧めします**。もしアクセストークンが本当にベアラートークンであればRFC6750のルールに従い、そうでなければ、カスタム認証スキームを作成しても、そのヘッダーを使用することは可能です。
Authorizationヘッダは、HTTPプロキシやサーバーによって認識され、特別に扱われます。したがって、リソースサーバへのアクセストークンの送信にこのようなヘッダを使用することで、認証されたリクエスト全般、特にAuthorizationヘッダの漏洩や意図しない保存の可能性を減らすことができます。
(出典: RFC 6819, Section 5.4.1)
OAuth 2.0はプロトコル、つまりトークンの転送方法を定義し、JWTはトークン形式を定義しています。
OAuth2.0とJWT認証は、クライアントがリソースサーバにトークンを提示する(第2段階)において、ヘッダでトークンを渡すという点で類似した外観を持っています。
しかし、JWT認証は標準規格ではないので、クライアントが最初にトークンを取得する方法(第1段階)は規定されていません。OAuthは、認証サーバーと呼ばれるものから、クライアントがアクセストークンを取得するための様々な方法を定義しているのです。
つまり、JWTは単なるトークンフォーマットであり、OAuth 2.0はプロトコル(トークンフォーマットとしてJWTを使用する*可能性がある)であるというのが本当の違いです。
まず、JWTとOAuthを区別する必要があります。基本的に、JWTはトークンフォーマットです。OAuthは、JWTをトークンとして使用できる認可プロトコルです。OAuthはサーバーサイドとクライアントサイドのストレージを使用します。もし、本当のログアウトをしたいのであれば、OAuth2を使用する必要があります。JWTトークンを使った認証では、実際にログアウトすることはできません。なぜなら、トークンを管理する認証サーバーを持たないからです。サードパーティのクライアントにAPIを提供する場合は、OAuth2も使用する必要があります。OAuth2は非常に柔軟です。JWTの実装は非常に簡単で、実装に時間がかかることはありません。もし、あなたのアプリケーションがこのような柔軟性を必要とするならば、OAuth2 を使うべきでしょう。しかし、このようなユースケースを必要としないのであれば、OAuth2 を実装するのは時間の無駄です。
XSRFトークンは、すべてのレスポンス・ヘッダで常にクライアントに送信されます。CSRFトークンがJWTトークンの中で送信されるかどうかは問題ではありません。なぜなら、CSRFトークンはそれ自体でセキュリティが確保されているからです。したがって、JWTの中にCSRFトークンを送ることは不要です。
JWT(JSON Webトークン)-これは単なるトークン形式です。 JWTトークンはJSONでエンコードされたデータ構造であり、発行者、件名(クレーム)、有効期限などに関する情報が含まれています。 改ざん防止と信頼性について署名されており、対称または非対称のアプローチを使用してトークン情報を保護するために暗号化できます。 JWTはSAML 1.1 / 2.0よりもシンプルで、すべてのデバイスでサポートされており、SWT(Simple Web Token)よりも強力です。
OAuth2 -OAuth2は、ユーザーが参照ベースのWebアプリ、ネイティブモバイルアプリ、デスクトップアプリなどのクライアントソフトウェアを使用してデータにアクセスしたいという問題を解決します。 OAuth2は承認のためのものであり、クライアントソフトウェアは、アクセストークンを使用してエンドユーザーの半分以上のリソースにアクセスすることを許可できます。
OpenID Connect -OpenID ConnectはOAuth2の上に構築され、認証を追加します。 OpenID Connectは、UserInfo Endpoint、IDトークン、OpenID Connectプロバイダーの検出と動的登録、セッション管理など、OAuth2にいくつかの制約を追加します。 JWTはトークンの必須フォーマットです。
CSRF保護-ブラウザのCookieにトークンを保存しない場合は、CSRF保護を実装する必要はありません。
詳細については、http://proficientblog.com/microservices-security/をご覧ください。
ここで答えた誰もがOAUTHの論点を逃したようです。
ウィキペディアから。
OAuthはアクセス委任のオープンスタンダードであり、インターネットユーザーがWebサイトまたはアプリケーションに他のWebサイトの情報へのアクセスを許可する方法として一般的に使用されますが、パスワードは与えられません。[1]このメカニズムは、Google、Facebook、Microsoft、Twitterなどの企業で使用され、ユーザーは自分のアカウントに関する情報をサードパーティのアプリケーションまたはWebサイトと共有できます。
ここでの重要なポイントは「アクセス委任」です。 OTPのような多要素認証に裏打ちされたid / pwdベースの認証があり、さらにパスへのアクセスを保護するために使用されるJWT(OAUTHのスコープなど)によって保護され、アクセス。
エンドポイントで再度ホストされている信頼できるWebサイト(またはアプリ)を介してのみ消費者がリソース(エンドポイント)にアクセスする場合、OAUTHを使用する意味はありません。
リソース所有者(ユーザー)がサードパーティのクライアント(外部)を介してリソース(エンドポイント)にアクセスしたい場合に、「OAUTHプロバイダー」である場合にのみ、OAUTH認証にアクセスできます。アプリ)。< / b>そして、それは一般的に乱用することができますが、まったく同じ目的のために正確に作成されます。
別の重要な注意:< br />。 JWTとOAUTHには「認証」という単語を自由に使用していますが、どちらも認証メカニズムを提供していません。 はい、1つはトークンメカニズムで、もう1つはプロトコルですが、認証されると、承認(アクセス管理)にのみ使用されます。 OPENIDタイプ認証または独自のクライアント資格情報を使用して、OAUTHをバックアップする必要があります。
JWTは、当事者間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義するオープンスタンダードです。 これは、エンコードされたクレーム(トークン)を2つの当事者(クライアントとサーバー)間で転送できるようにする認証プロトコルであり、トークンはクライアントの識別時に発行されます。 その後のリクエストごとにトークンを送信します。
一方、OAuth2は承認フレームワークであり、フレームワークによって定義された一般的な手順とセットアップがあります。 JWTはOAuth2内のメカニズムとして使用できます。
これについて詳しくは、こちらをご覧ください。
https://stackoverflow.com/questions/32964774/oauth-or-jwt-which-one-to-use-and-why / 48333725#48333725。
Jwtは、署名されたアクセストークンの発行と検証に関する一連の厳密な指示です。 トークンには、ユーザーへのアクセスを制限するためにアプリが使用するクレームが含まれています。
一方、OAuth2はプロトコルではなく、委任された承認フレームワークです。 ユーザーとアプリケーションがプライベートとパブリックの両方の設定で他のアプリケーションへの特定の権限を承認できるようにするための非常に詳細なガイドラインを考えてください。 OAUTH2の上にあるOpenID Connectを使用すると、認証と承認が得られます。複数の異なる役割、システムのユーザー、APIなどのサーバー側アプリ、およびWebサイトやネイティブモバイルアプリなどのクライアントが、それぞれで認証する方法の詳細がわかります。
注 oauth2は、さまざまなアプリケーションに拡張可能なjwt、柔軟な実装で動作します。