JWT用の最善のHTTP認証ヘッダータイプ

Question

JWT tokensの場合に最も適切なAuthorization HTTPヘッダータイプが何か不思議です。

おそらく最も一般的なタイプの1つは、Basicです。たとえば、

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

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

また、私は、例えば、およそベアラタイプを聞いた：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

は、しかし、私はその意味を知りません。それはクマに関連しているのですか？

HTTP AuthorizationヘッダーでJWTトークンを使用する特別な方法はありますか？我々はBearerを使用する必要があります、または私達は簡素化し、ちょうど使用する必要があります。

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

感謝。

編集：

それとも、単にJWT HTTPヘッダー：

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Answer 1

JWTトークンは、OAuthなしで使用できます。

したがって、単純な"Authorization: JWT <your_token>"がより適切でしょう。

例：

curl -H "Authorization: JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ" https://api.domain.tld/me/account 

Answer 2

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

このスキームは、RFC6750で記述されています。

例：https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture：あなたはより強力なセキュリティ保護が必要な場合は

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

、あなたはまた、次のIETFのドラフトを考慮することができます。この草案は、（放棄された？）https://tools.ietf.org/html/draft-ietf-oauth-v2-http-macの良い代替案と思われます。

このRFCと上記の仕様がOAuth2 Frameworkプロトコルに関連していても、クライアントとサーバーの間のトークン交換を必要とするその他のコンテキストで使用できます。

JWTのカスタムスキームとは異なり、ご質問にはthe Bearer one is registered at the IANAと記載されています。 BasicとDigest認証スキームに関する

が、それらはユーザー名とシークレットを使用して認証するために専用されているという状況ではそうは適用されません（RFC7616とRFC7617を参照してください）。

Answer 3

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

Errr ...いいえ！

ここRFC 6750に応じ無記名トークンの定義です：

1.2. Terminology

ベアラートークン

トークンを所有している当事者性を有するセキュリティトークン（「運送人」）は、トークンを所有している他の当事者が行うことのできる方法でトークンを使用することができます。ベアラトークンを使用することは、ベアラが暗号鍵材料（所持証明）の所有を証明することを要求しない。

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

可能な限り標準に固執し、独自の認証方式を作成しないでください。

---

アクセストークンはBearer認証スキームを使用してAuthorizationリクエストヘッダで送信されなければならない：

2.1. Authorization Request Header Field

HTTP /によって定義Authorizationリクエストヘッダフィールドにアクセストークンを送信1.1の場合、クライアントはBearer認証方式を使用してアクセストークンを送信します。例えば

：

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

[...]

クライアントはBearer HTTP認証方式にAuthorizationリクエストヘッダフィールドを使用して、ベアラトークンを使用して認証要求をしなければなりません。 [...]無効またはトークン行方不明の場合

、Bearer方式はWWW-Authenticateレスポンスヘッダに含まれるべきである：

3. The WWW-Authenticate Response Header Field

保護されたリソース要求が含まれていない場合保護されたリソースへのアクセスを可能にするアクセストークンを含んでいない場合、リソースサーバーはHTTP WWW-Authenticate応答ヘッダーフィールド[...]を含まなければなりません。

この仕様で定義されているすべての課題はauth-scheme値Bearerを使用しなければならない。このスキームには、1つ以上のauth-param値が続かなければならない（MUST）。 [...]。期限切れのアクセストークンを使用した認証の試行と

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"