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