JWTを使用したステートレス認証モデルを備えた新しいSPAがあります。単純なトークンヘッダーの代わりにすべてのリクエストに対して「ベアラートークン」を送信するように依頼するなど、認証フローについてOAuthを参照するようにしばしば求められますが、OAuthは単純なJWTベースの認証よりもはるかに複雑だと思います。主な違いは何ですか、JWT認証をOAuthのように動作させる必要がありますか？
XSRF-TOKENとしてJWTを使用してXSRFを防止していますが、それらを個別に保持するように求められますか？それらを分離しておくべきですか？ここでの助けは高く評価され、コミュニティのための一連のガイドラインにつながるかもしれません。
回答:
TL; DR 単一のクライアントアプリケーション、単一のAPIなどの非常に単純なシナリオの場合、OAuth 2.0を使用しても効果が得られない可能性があります。一方で、多数の異なるクライアント（ブラウザベースのネイティブモバイル、サーバー側）など）その後、OAuth 2.0ルールを使用すると、独自のシステムをローリングするよりも管理しやすくなる場合があります。
別の回答で述べたように、JWT（Learn JSON Web Tokens）は単なるトークン形式であり、デジタル署名されているため、検証および信頼できる方法でパーティー間でデータを送信するためのコンパクトで自己完結型のメカニズムを定義します。さらに、JWTのエンコーディングルールにより、これらのトークンはHTTPのコンテキスト内で非常に使いやすくなっています。
自己完結型であるため（実際のトークンには特定のサブジェクトに関する情報が含まれています）、ステートレス認証メカニズム（別名Look mum、セッションなし）の実装にも適しています。このルートをたどる場合、保護されたリソースへのアクセスを許可するためにパーティーが提示しなければならない唯一のものはトークン自体です。問題のトークンは、ベアラートークンと呼ばれます。
実際には、実行していることは、無記名トークンに基づくものとしてすでに分類されている可能性があります。ただし、OAuth 2.0関連の仕様（RFC 6750を参照）で指定されているベアラートークンを使用していないことを考慮してください。これは、AuthorizationHTTPヘッダーに依存し、Bearer認証スキームを使用することを意味します。
正確な詳細を知らずにCSRFを防止するためのJWTの使用に関しては、その実践の有効性を確認することは困難ですが、正直に言うと、正しくないか、価値があるように見えません。次の記事（Cookies対Tokens：The Definitive Guide）は、この主題、特にXSSおよびXSRF保護セクションを読むのに役立ちます。
最後のアドバイスとして、OAuth 2.0を完全に使用する必要がない場合でも、カスタムヘッダーではなく、Authorizationヘッダー内でアクセストークンを渡すことを強くお勧めします。それらが本当にベアラートークンである場合は、RFC 6750のルールに従います。そうでない場合は、いつでもカスタム認証スキームを作成し、そのヘッダーを使用できます。
承認ヘッダーはHTTPプロキシとサーバーによって認識され、特別に処理されます。したがって、アクセストークンをリソースサーバーに送信するためにこのようなヘッダーを使用すると、認証された要求、特にAuthorizationヘッダーの漏洩や意図しない格納の可能性が低くなります。
（出典：RFC 6819、セクション5.4.1）
OAuth 2.0はプロトコルを定義します。つまり、トークンの転送方法を指定し、JWTはトークンの形式を定義します。
OAuth 2.0と「JWT認証」は、クライアントがトークンをリソースサーバーに提示する（2番目の）ステージに似ていますが、トークンはヘッダーで渡されます。
ただし、「JWT認証」は標準ではなく、クライアントが最初にトークンを取得する方法（最初の段階）を指定していません。ここでOAuthの複雑さを認識しています。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 Tokens） -これは単なるトークン形式です。JWTトークンは、JSONエンコードされたデータ構造で、発行者、件名（クレーム）、有効期限などに関する情報が含まれています。改ざん防止と認証のために署名され、対称または非対称のアプローチを使用してトークン情報を保護するために暗号化できます。JWTはSAML 1.1 / 2.0よりもシンプルで、すべてのデバイスでサポートされており、SWT（Simple Web Token）よりも強力です。
OAuth2 -OAuth2は、ユーザーがブラウズベースのウェブアプリ、ネイティブモバイルアプリ、デスクトップアプリなどのクライアントソフトウェアを使用してデータにアクセスしたいという問題を解決します。OAuth2は認証専用です。クライアントソフトウェアは、アクセストークンを使用してエンドユーザーに代わってリソースにアクセスすることを認証できます。
OpenID Connect -OpenID ConnectはOAuth2の上に構築され、認証を追加します。OpenID Connectは、UserInfoエンドポイント、IDトークン、OpenID Connectプロバイダーの検出と動的登録、セッション管理などの制約をOAuth2に追加します。JWTはトークンの必須フォーマットです。
CSRF保護 -ブラウザーのCookieにトークンを保存しない場合は、CSRF保護を実装する必要はありません。
詳細については、http：//proficientblog.com/microservices-security/をご覧ください。
ここで回答した全員がOAUTHの要点を逃したようです
ウィキペディアから
OAuthはアクセス委任のオープンスタンダードであり、インターネットユーザーがウェブサイトやアプリケーションに他のウェブサイト上の情報へのアクセスを許可する方法として一般的に使用されますが、パスワードは与えられません。[1] このメカニズムは、Google、Facebook、Microsoft、Twitterなどの企業が、ユーザーが自分のアカウントに関する情報をサードパーティのアプリケーションまたはWebサイトと共有できるようにするために使用されます。
ここでのポイントはaccess delegationです。OTPのような多要素認証に裏打ちされたID / pwdベースの認証があり、さらにパス（OAUTHのスコープのような）へのアクセスを保護し、アクセス
エンドポイントで再びホストされている信頼できるWebサイト（またはアプリ）を介してのみユーザーがリソース（エンドポイント）にアクセスする場合、OAUTHを使用する意味はありません。
リソース所有者（ユーザー）がサードパーティのクライアント（外部アプリ）を介してリソース（エンドポイント）にアクセスする場合にのみ、OAUTH provider OAUTH認証を実行できます。そして、あなたはそれを一般的に乱用することができますが、それは同じ目的のために正確に作成されます
もう1つの重要な注意： JWTとOAUTHを
自由に使用していますauthenticationが、どちらも認証メカニズムを提供していません。はい、1つはトークンメカニズムで、もう1つはプロトコルですが、認証されると、承認（アクセス管理）にのみ使用されます。OPENIDタイプの認証または独自のクライアント認証情報を使用してOAUTHをバックアップする必要があります
JWTとOAuthの主な違いを見つける
OAuth 2.0はプロトコルを定義し、JWTはトークン形式を定義します。
OAuthでは、JWTをトークン形式として使用することも、ベアラートークンであるアクセストークンとして使用することもできます。
OpenID Connectは、主にトークン形式としてJWTを使用します。
JWTは、当事者間で情報を安全に送信するためのコンパクトで自己完結型の方法を定義するオープンスタンダードです。これは、エンコードされたクレーム（トークン）を2つのパーティ（クライアントとサーバー）間で転送できる認証プロトコルであり、クライアントの識別時にトークンが発行されます。後続のリクエストごとに、トークンを送信します。
一方、OAuth2は承認フレームワークであり、フレームワークによって定義された一般的な手順と設定があります。JWTは、OAuth2内のメカニズムとして使用できます。
これについて詳しくは、こちらをご覧ください。
よくある質問ですが、あまり賢明ではありません。JWTはトークンの一種であり、OAuthはトークンの分配方法を記述するフレームワークです。
「フレームワーク」とはどういう意味ですか？トークンのリクエストに使用できる、およびリクエストのシーケンスとそれらのフォーマットのみを使用できます。OAuthv2は、異なるシナリオの個別の「フロー」または許可タイプを記述し、特定のフローのセキュリティを拡張するための異なる拡張（PKCEなど）を備えています。
OAuthV2付与によるトークン要求の結果は...トークンです。次に、そのものが「無記名トークン」として使用されます。つまり、トークンを保持しているすべての当事者が、サービスのapi要求を行うときにそれを提示できることを意味します（たとえば、「ストアドバリューカードの残高は？」）。無記名トークンとして、それは現金のように機能します。持っていれば使えます。（現金とは異なり、トークンは使い捨てではありません。おそらく、公共交通機関での終日乗車券か、ディズニーワールドでの終日切符の方がいいでしょう。）
JWTは特定のタイプのトークンであり、JWTはOAuth Bearerトークンとして完全に使用できます。実際、これは最も一般的な方法です。それを踏まえると、「JWT vs OAuth」は、リンゴとリンゴカートの比較です。
「OAuthトークン」は常に不透明トークン-固有の意味を含まない英数字のランダムなシーケンス-を意味し、OAuthトークンディスペンサリーによって付与され、同じOAuthディスペンサリーシステムによってのみ検証できるとしばしば考えられます。ただし、これが唯一のOAuthトークンではありません。不透明トークンは一種のトークンです。JWTは別の種類のOAuthトークンとして使用できます。
対照的に、JWTは不透明ではありません。JWTは「ポインタ」または情報への参照ではありません。実際には、トークンを持つ任意の当事者が抽出および解釈できる特定の情報がたくさん含まれています。JWTには実際の情報が含まれているため、JWTは大きくなる可能性があります。含まれるクレーム、および署名に使用されたアルゴリズムに応じて、300バイト、500バイト、またはそれ以上。人々が「JWTは自己検証している」と言うとき、JWTの所有者は誰でもそれを開いて検証し、提示されたクレームに基づいて承認を決定できます。JWTの検証とは、その構造を検証し、base64エンコードをデコードし、キーが正しいことを検証し、署名を検証し、必要なクレームがトークンに存在することを検証し、有効期限を確認することを意味します。簡単なことではありません むしろ多段階のプロセスですが、もちろんこれを活用するさまざまなプログラミング言語のライブラリがたくさんあります。もちろん、Apigee Edge APIプロキシ内でこれを行うのに役立つVerifyJWTポリシーがあります。重要なのは、任意の所有者または受信者がトークンを検証できることです。このため、JWTは「フェデレーション」をサポートしていると言います。誰でもトークンを生成でき、誰でもトークンを読み取って検証できます。
カスタムクレーム。JWTトークンと不透明OAuthトークンの両方が、サブジェクトに関するカスタムクレームを運ぶことができます。セキュリティ。どちらも無記名トークンです。どちらも秘密として保護する必要があります。有効期限。どちらも有効期限をマークできます。どちらもリフレッシュできます。認証メカニズムまたはエクスペリエンス。どちらも同じユーザーエクスペリエンスを提供できます。
Jwtは、署名されたアクセストークンを発行および検証するための一連の厳密な命令です。トークンには、アプリがユーザーへのアクセスを制限するために使用するクレームが含まれています
一方、OAuth2はプロトコルではなく、委任された承認フレームワークです。ユーザーとアプリケーションに、プライベートとパブリックの両方の設定で他のアプリケーションへの特定の権限を許可させるための非常に詳細なガイドラインを考えてください。OAUTH2の上にあるOpenID Connectは、AuthenticationとAuthorizationを提供します。itは、複数の異なる役割、システム内のユーザー、APIのようなサーバー側アプリ、およびWebサイトやネイティブモバイルアプリなどのクライアントが各otheで認証できる方法を詳しく説明します
oauth2は、さまざまなアプリケーションに拡張可能なjwt、柔軟な実装で動作することに注意してください。