JWTに最適なHTTP Authorizationヘッダータイプ

JWTトークンに最適なAuthorizationHTTPヘッダーの種類は何でしょうか。

おそらく最も人気のあるタイプの1つはBasicです。例えば：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

ログインとパスワードなどの2つのパラメーターを処理します。したがって、JWTトークンには関係ありません。

また、私は例えばベアラータイプについて聞いた：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

しかし、その意味はわかりません。それはクマに関連していますか？

HTTP AuthorizationヘッダーでJWTトークンを使用する特定の方法はありますか？を使用するBearerか、単純化して使用するだけですか？

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

ありがとう。

編集：

または、たぶん、JWTHTTPヘッダーだけです：

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

クライアントがアクセストークン（JWTまたはその他のトークン）を送信するのに最適なHTTPヘッダーはAuthorization、Bearer認証スキームを含むヘッダーです。

このスキームはRFC6750で説明されています。

例：

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ

より強力なセキュリティ保護が必要な場合は、次のIETFドラフトを検討することもできます：https : //tools.ietf.org/html/draft-ietf-oauth-pop-architecture。このドラフトは（放棄された？）https://tools.ietf.org/html/draft-ietf-oauth-v2-http-macの良い代替案のようです。

このRFCと上記の仕様がOAuth2フレームワークプロトコルに関連している場合でも、クライアントとサーバー間のトークン交換が必要な他のコンテキストで使用できることに注意してください。

カスタムとは異なりJWT、あなたの質問に言及スキーム、1は、IANAに登録されています。Bearer

BasicおよびDigest認証スキームについては、ユーザー名とシークレット（RFC7616およびRFC7617を参照）を使用した認証に特化しているため、そのコンテキストには適用されません。

短い答え

Bearer認証方式は、あなたが探しているものです。

長い答え

それはクマに関連していますか？

エラー...いいえ:)

Oxford Dictionariesによると、ベアラーの定義は次のとおりです。

無記名 _{^{/ ˈbɛːrə /}}
名詞

1. 何かを運ぶまたは保持する人または物。

2. 小切手またはその他の支払い命令を提示する人。

最初の定義には、次の同義語が含まれています：メッセンジャー、エージェント、コンベヤー、使者、運送業者、プロバイダー。

そして、RFC 6750によるベアラートークンの定義を次に示します。

1.2。用語

無記名トークン

トークンを所持しているすべての当事者（「所有者」）が、トークンを所持している他の当事者と同じようにトークンを使用できるという特性を持つセキュリティトークン。ベアラートークンを使用する場合、ベアラーは暗号化キーマテリアル（所有証明）の所有を証明する必要はありません。

Bearer認証方式であるIANAに登録し、元々で定義されたRFC 6750のOAuth 2.0認証フレームワークのために、何も使用してからあなたを停止しないBearerのOAuth 2.0を使用しないアプリケーションでアクセストークンためのスキームを。

できる限り標準に準拠し、独自の認証スキームを作成しないでください。

アクセストークンはAuthorization、Bearer認証スキームを使用してリクエストヘッダーで送信する必要があります。

2.1。承認リクエストヘッダーフィールド

AuthorizationHTTP / 1.1で定義されたリクエストヘッダーフィールドでアクセストークンを送信する場合、クライアントはBearer認証方式を使用してアクセストークンを送信します。

例えば：

GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

[...]

クライアントAuthorizationは、BearerHTTP承認スキームのリクエストヘッダーフィールドを使用して、ベアラートークンで認証済みリクエストを作成する必要があります（SHOULD）。[...]

トークンが無効または欠落している場合は、BearerスキームをWWW-Authenticate応答ヘッダーに含める必要があります。

3. WWW-Authenticate応答ヘッダーフィールド

保護されたリソース要求に認証資格情報が含まれていないか、保護されたリソースへのアクセスを可能にするアクセストークンが含まれていない場合、リソースサーバーはHTTP WWW-Authenticate応答ヘッダーフィールド[...]を含める必要があります。

この仕様で定義されているすべてのチャレンジでは、auth-scheme値を使用する必要がありますBearer。このスキームの後には、1つ以上のauth-param値が続く必要があります。[...]。

たとえば、認証されていない保護されたリソース要求に応答して：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

また、有効期限が切れたアクセストークンを使用した認証試行を伴う保護されたリソースリクエストへの応答：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                         error="invalid_token",
                         error_description="The access token expired"