JWT を使用したステートレス認証モデルを備えた新しい SPA があります。認証フローについては OAuth を参照するようによく求められます。たとえば、単純なトークン ヘッダーではなく、すべてのリクエストに対して「ベアラー トークン」を送信するように求められますが、OAuth は単純な JWT ベースの認証よりもはるかに複雑だと思います。主な違いは何ですか。JWT 認証を OAuth のように動作させる必要がありますか。
XSRF を防ぐために JWT を XSRF-TOKEN として使用していますが、これらを別々にしておくように求められています。別々にしておくべきでしょうか? ここでの助けはありがたく、コミュニティのためのガイドラインのセットにつながるかもしれません。
ベストアンサー1
TL;DR単一のクライアント アプリケーション、単一の API など、非常に単純なシナリオの場合は、OAuth 2.0 に移行してもメリットがない可能性があります。一方、さまざまなクライアント (ブラウザー ベース、ネイティブ モバイル、サーバー側など) がある場合は、OAuth 2.0 のルールに従うことで、独自のシステムを構築するよりも管理しやすくなる可能性があります。
別の回答で述べたように、JWT（JSON Webトークンを学ぶ) は単なるトークン形式です。デジタル署名されているため検証および信頼でき、関係者間でデータを送信するためのコンパクトで自己完結的なメカニズムを定義します。さらに、JWT のエンコード ルールにより、これらのトークンは HTTP のコンテキスト内で非常に簡単に使用できます。
自己完結型 (実際のトークンには特定の主題に関する情報が含まれています) であるため、ステートレス認証メカニズム (つまり、セッションはありません) を実装する場合にも適しています。この方法を使用する場合、保護されたリソースへのアクセスを許可されるために当事者が提示する必要があるのはトークン自体のみであり、問題のトークンはベアラー トークンと呼ぶことができます。
実際には、あなたが行っていることはすでにベアラートークンベースに分類できます。ただし、OAuth 2.0関連の仕様で指定されているベアラートークンを使用していないことに注意してください（参照：RFC 6750）。これは、AuthorizationHTTP ヘッダーに依存し、Bearer認証スキームを使用することを意味します。
CSRF を防ぐための JWT の使用について: 正確な詳細を知らなければ、その方法の有効性を確認することは困難です。正直に言うと、それは正しくも価値もないように思われます。次の記事 (クッキーとトークン: 決定版ガイド) は、このテーマ、特にXSS および XSRF 保護のセクションについて読むと役に立つかもしれません。
最後にアドバイスを 1 つ。完全な OAuth 2.0 を使用する必要がない場合でも、カスタム ヘッダーを使用するのではなく、ヘッダー内でアクセス トークンを渡すことを強くお勧めしますAuthorization。それらが実際にベアラー トークンである場合は、RFC 6750 のルールに従ってください。そうでない場合は、いつでもカスタム認証スキームを作成し、そのヘッダーを使用することができます。
Authorization ヘッダーは、HTTP プロキシとサーバーによって認識され、特別に処理されます。したがって、リソース サーバーにアクセス トークンを送信するためにこのようなヘッダーを使用すると、認証されたリクエスト全般、特に Authorization ヘッダーが漏洩したり、意図せずに保存される可能性が減ります。
（ソース：RFC 6819、セクション 5.4.1）