Melhor tipo de header de autorização HTTP para o JWT

Eu estou querendo saber qual é o melhor tipo de header HTTP de Authorization para tokens JWT .

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

 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== 

Ele manipula dois parâmetros, como login e senha. Por isso, não é relevante para tokens JWT.

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

 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

No entanto, não sei o seu significado. Está relacionado com os ursos?

Existe uma maneira específica de usar tokens JWT no header de Authorization HTTP? Devemos usar o Bearer , ou devemos simplificar e apenas usar:

 Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

Obrigado.

Editar:

Ou talvez apenas um header HTTP do JWT :

 JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 

O melhor header HTTP para o seu cliente enviar um token de access (JWT ou qualquer outro token) é o header de Authorization com o esquema de autenticação do Bearer .

Este esquema é descrito pelo RFC6750 .

Exemplo:

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

Se você precisar de 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 para o (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 troca de tokens entre um cliente e um servidor.

Ao contrário do esquema JWT personalizado que você mencionou na sua pergunta, o Bearer é registrado na IANA .

Quanto aos esquemas de autenticação Basic e Digest , eles são dedicados à autenticação usando um nome de usuário e um segredo (consulte RFC7616 e RFC7617 ), portanto, não são aplicáveis ​​nesse contexto.

Está relacionado com os ursos?

Errr … Provavelmente não. Aqui está a definição de token de portador de acordo com o RFC 6750 :

1.2. Terminologia

Ficha de Portador

Um token de segurança com a propriedade que qualquer parte na posse do token (um “portador”) pode usar o token de qualquer maneira que qualquer outra parte na posse dele possa. O uso de um token de portador não requer que o portador comprove a posse de material de chave criptográfica (comprovante de posse).

O esquema do Bearer é originalmente definido no RFC 6750 para a estrutura de autorização do OAuth 2.0, mas nada impede que você use o esquema Bearer para tokens de access 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 access deve ser enviado no header da solicitação de Authorization usando o esquema de autenticação do Bearer :

2.1. Campo de Cabeçalho da Solicitação de Autorização

Ao enviar o token de access no campo de header de solicitação de Authorization definido pelo HTTP / 1.1, o cliente usa o esquema de autenticação do Bearer para transmitir o token de access.

Por exemplo:

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

[…]

Os clientes DEVERÃO fazer solicitações autenticadas com um token portador usando o campo de header de solicitação de Authorization com o esquema de autorização HTTP do Bearer . […]

Em caso de token inválido ou ausente, o esquema de Bearer deve ser incluído no header de resposta WWW-Authenticate :

3. O campo de header de resposta de autenticação da WWW

Se a solicitação de recurso protegido não include credenciais de autenticação ou não contiver um token de access que permita o access ao recurso protegido, o servidor de resources DEVE include o campo de header de resposta HTTP WWW-Authenticate […].

Todos os desafios definidos por esta especificação DEVEM usar o valor de Bearer esquema auth. Este esquema DEVE ser seguido por um ou mais valores auth-param. […].

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 access expirado:

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