web-dev-qa-db-ja.com

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

私は JWTトークンに最適なAuthorization HTTPヘッダータイプが何であるか疑問に思います 。

おそらく最も普及しているタイプの1つはBasicです。例えば：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

また、私はBearer typeについて聞きました、例えば：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

しかし、その意味はわかりません。それはクマと関係がありますか？

HTTPのAuthorizationヘッダでJWTトークンを使う特別な方法はありますか？ Bearerを使うべきか、あるいは単純化して単に使うべきですか：

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

ありがとう。

編集：

あるいはJWTというHTTPヘッダだけでもいいでしょう：

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
http-headersjwt
170
Zag zag..

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

この計画は RFC6750 によって記述されています。

例：

GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ

より強力なセキュリティ保護が必要な場合は、次の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スキームとは異なり、 BearerはIANAに登録されています 。

BasicおよびDigest認証方式に関しては、それらはユーザ名と秘密（ RFC7616 および RFC 7617 を参照）を使った認証専用であるため、この文脈では適用できません。

234
Florent Morselli

短い答え

Bearer認証スキームが探しています。

長い答え

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

エラー...いいえ:)

Oxford Dictionaries によると、ここにbearerの定義があります：

ベアラー / ˈbɛːrə /
名詞

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

  2. お金を支払うために小切手またはその他の注文を提示する人。

最初の定義には、messenger、agent、conveyor、 エメッセリー、キャリア、provider。

RFC 6750 によるベアラートークンの定義は次のとおりです。

1.2。用語

ベアラートークン

トークンの所有者（「持ち手」）が、トークンを所有する他の当事者が使用できる方法でトークンを使用できるプロパティを持つセキュリティトークン。ベアラトークンを使用する場合、ベアラは暗号化キーマテリアルの所有を証明する必要はありません（所有の証明）。

Bearer認証スキームは IANA に登録されており、元々 RFC 6750 でOAuth 2.0認証フレームワーク用に定義されています。しかし、OAuth 2.0を使用しないアプリケーションでアクセストークンにBearerスキームを使用することを妨げるものはありません。

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

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

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

HTTP/1.1で定義されているAuthorization要求ヘッダーフィールドでアクセストークンを送信する場合、クライアントはBearer認証スキームを使用してアクセストークンを送信します。

例えば：

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

[...]

クライアントは、Authorization HTTP承認スキームでBearer要求ヘッダーフィールドを使用して、ベアラートークンで認証された要求を行う必要があります。 [...]

トークンが無効または欠落している場合、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"
59
cassiomolin