[解決済み] JWT認証とOAuth認証の主な違いは何ですか？

質問事項

JWTを使用したステートレス認証モデルを持つ新しいSPAを持っています。私はよく、単純なトークンヘッダーの代わりにリクエストごとに「ベアラートークン」を送信するよう求めるような認証フローにOAuthを参照するよう求められますが、私はOAuthが単純なJWTベースの認証よりもはるかに複雑だと考えています。主な違いは何ですか？JWT認証をOAuthのように動作させればよいのでしょうか？

また、XSRF対策としてJWTをXSRF-TOKENとして使用していますが、両者を分けて考えるように言われているのですが？別々にしたほうがいいのでしょうか？また、コミュニティのためのガイドラインにつながるかもしれません。

どのように解決するのですか？

TL;DR もし、単一のクライアントアプリケーション、単一のAPIといった非常にシンプルなシナリオであれば、OAuth 2.0にすることは得策ではないかもしれません。一方、多くの異なるクライアント（ブラウザベース、ネイティブモバイル、サーバーサイドなど）がある場合は、OAuth 2.0のルールに従ったほうが、独自のシステムを構築するより管理しやすいかもしれません。

別の回答で述べたように、JWT( JSONウェブトークンを学ぶ これは、当事者間でデータを伝送するためのコンパクトで自己完結したメカニズムを定義したもので、デジタル署名されているため検証や信頼が可能です。さらに、JWTのエンコーディング規則は、これらのトークンをHTTPのコンテキスト内で非常に簡単に使用できるようにします。

また、自己完結型（実際のトークンには特定の対象に関する情報が含まれている）であるため、ステートレス認証機構（いわゆる ママ見て！セッションがない！」。 ). このように、保護されたリソースへのアクセスを許可するために当事者が提示しなければならないものがトークンだけである場合、そのトークンはベアラートークンと呼ばれることがあります。

実際には、あなたがやっていることは、すでにベアラートークンに基づくものと分類できます。しかし、OAuth 2.0 関連の仕様で規定されているようなベアラートークンを使っているわけではないことを考慮してください ( RFC 6750 ). それはつまり Authorization HTTPヘッダを使用し Bearer の認証スキームを使用します。

CSRFを防ぐためにJWTを使用することについては、詳細が分からないのでその有効性を確認することは困難ですが、正直なところ、それは正しくなく、また価値がないように思われます。以下の記事( クッキーとトークン。決定版ガイド ) は、このテーマについて読むのに役に立つかもしれません。 XSSとXSRFの保護 のセクションを参照してください。

最後のアドバイスとして、たとえOAuth 2.0をフルに使う必要がないとしても、私は の中でアクセストークンを渡すことを強くお勧めします。 Authorization ヘッダーを使用する代わりに . もし、本当にベアラートークンであれば、RFC6750のルールに従ってください。そうでない場合は、カスタムの認証スキームを作成しても、そのヘッダーを使用することができます。

Authorizationヘッダは、HTTPプロキシやサーバによって認識され、特別に扱われます。したがって、リソースサーバにアクセストークンを送信するためにこのようなヘッダを使用すると、認証されたリクエスト全般、特に Authorization ヘッダの漏洩や意図しない保存の可能性を減らすことができます。

(出典 RFC6819、セクション5.4.1 )