JWTとBearer Tokenの違いは何ですか？
Basic、Digest、OAuth2.0、JWT、およびBearer Tokenのような承認について何かを学んでいます。
今、質問があります。
JWTがOAuth2.0標準でAccess_Tokenとして使用されていることはご存じでしょう。 JWTはRFC 7519にあり、ベアラートークンはRFC 6750にあります。
たとえば、ベアラー：
Authorization: Bearer <token>
AJAXでトークンをサーバーに送信するか、URLのクエリ文字列にトークンを追加していました。トークンはリクエストヘッダーに追加することでも送信できることを知っています。それは、トークンをAuthorization Bearerヘッダーに追加する必要があるということですか？
JWTとBearer Tokenの関係を教えてください。どうもありがとう。
JWTは、署名と暗号化が可能なJSONデータペイロードを含むトークンのエンコード標準です。
JWTは多くの目的に使用できますが、その中にはベアラートークンがあります。つまり、あるサービスに提示できる情報の一部（「ベアラー」であるため）が何かへのアクセスを許可します。
ベアラートークンは、HTTPリクエストにさまざまな方法で含めることができます。そのうちの1つ（おそらく優先）はAuthorizationヘッダーです。ただし、リクエストパラメータ、Cookie、またはリクエスト本文に含めることもできます。それは主にあなたとあなたがアクセスしようとしているサーバーの間です。
簡潔な答え
JWTは、encodeおよびverifyクレームへの便利な方法です。
Bearerトークンは、許可に使用される可能性のある任意の文字列です。
コンテキスト（ストーリータイム）
数年前、JWT革命以前は、<token>は本質的な意味のない単なる文字列でした。 2pWS6RQmdZpE0TQ93X。次に、そのトークンは、そのトークンのclaimsを保持するデータベースで検索されました。このアプローチの欠点は、トークンが使用されるたびにDBアクセス（またはキャッシュ）が必要になることです。
JWTencodeおよびverify（署名による）独自のクレーム。これにより、人々はステートレスな短命のJWTを発行できます（自己完結型で、他の人に依存しないでください）。 DBにアクセスする必要はありません。 JWTを発行するサービスのみがDB /永続層（おそらく遭遇するrefresh_token）へのアクセスを心配する必要があるため、これによりDBの負荷が軽減され、アプリケーションアーキテクチャが簡素化されます。