Melhor tipo de cabeçalho de Autorização HTTP para JWT

Gostaria de saber qual é o melhor Authorizationtipo de cabeçalho HTTP apropriado para tokens JWT .

Um dos tipos provavelmente mais populares é Basic. Por exemplo:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Ele lida com dois parâmetros, como um login e uma senha. Portanto, não é relevante para os tokens JWT.

Além disso, ouvi falar do tipo Bearer , por exemplo:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

No entanto, eu não sei o seu significado. Está relacionado aos ursos?

Existe uma maneira específica de usar tokens JWT no Authorizationcabeçalho HTTP ? Devemos usar Bearerou simplificar e apenas usar:

Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

Obrigado.

Editar:

Ou talvez, apenas um JWTcabeçalho HTTP:

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

O melhor cabeçalho HTTP para o seu cliente enviar um token de acesso (JWT ou qualquer outro token) é o Authorizationcabeçalho com o Beareresquema de autenticação.

Este esquema é descrito pelo RFC6750 .

Exemplo:

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

Se você precisar de uma proteção de segurança mais forte, considere também o seguinte rascunho da IETF: https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture . Este rascunho parece ser uma boa alternativa ao (abandonado?) Https://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac .

Observe que, mesmo que essa RFC e as especificações acima estejam relacionadas ao protocolo OAuth2 Framework, elas podem ser usadas em qualquer outro contexto que exija uma troca de token entre um cliente e um servidor.

Diferente do JWTesquema personalizado mencionado na sua pergunta, o Bearerregistrado na IANA .

No que diz respeito aos esquemas de autenticação Basice Digest, eles são dedicados à autenticação usando um nome de usuário e um segredo (consulte RFC7616 e RFC7617 ), portanto não aplicável nesse contexto.

Resposta curta

O Beareresquema de autenticação é o que você está procurando.

Resposta longa

Está relacionado aos ursos?

Errr ... Não :)

De acordo com os Dicionários de Oxford , aqui está a definição de portador :

portador _{^{/ ˈbɛːrə /}}
substantivo

1. Uma pessoa ou coisa que carrega ou segura alguma coisa.

2. Uma pessoa que apresenta um cheque ou outro pedido para pagar dinheiro.

A primeira definição inclui os seguintes sinônimos: mensageiro , agente , transportador , emissário , transportadora , provedor .

E aqui está a definição de token do portador de acordo com a RFC 6750 :

1.2 Terminologia

Token do Portador

Um token de segurança com a propriedade de que qualquer parte em posse do token (um "portador") pode usá-lo de qualquer maneira que qualquer outra parte em posse dele. O uso de um token de portador não exige que o portador comprove a posse do material da chave criptográfica (prova de posse).

O Beareresquema de autenticação está registrado na IANA e originalmente definido no RFC 6750 para a estrutura de autorização do OAuth 2.0, mas nada impede você de usar o Beareresquema para tokens de acesso em aplicativos que não usam o OAuth 2.0.

Atenha-se aos padrões o máximo que puder e não crie seus próprios esquemas de autenticação.

Um token de acesso deve ser enviado no Authorizationcabeçalho da solicitação usando o Beareresquema de autenticação:

2.1 Campo do cabeçalho da solicitação de autorização

Ao enviar o token de acesso no Authorizationcampo de cabeçalho da solicitação definido por HTTP / 1.1, o cliente usa o Beareresquema de autenticação para transmitir o token de acesso.

Por exemplo:

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

[...]

Os clientes devem fazer solicitações autenticadas com um token de portador usando o Authorizationcampo de cabeçalho da solicitação com o Beareresquema de autorização HTTP. [...]

Em caso de token inválido ou ausente, o Beareresquema deve ser incluído no WWW-Authenticatecabeçalho da resposta:

3. O campo do cabeçalho de resposta WWW-Authenticate

Se a solicitação de recurso protegido não inclui credenciais de autenticação ou não contém um token de acesso que permita o acesso ao recurso protegido, o servidor de recursos DEVE incluir o WWW-Authenticatecampo de cabeçalho de resposta HTTP [...].

Todos os desafios definidos por esta especificação DEVEM usar o valor do esquema de autenticação Bearer. Este esquema deve ser seguido por um ou mais valores de parametros de autenticação. [...]

Por exemplo, em resposta a uma solicitação de recurso protegido sem autenticação:

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

E em resposta a uma solicitação de recurso protegido com uma tentativa de autenticação usando um token de acesso expirado:

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