Iniciar com JSON Web Tokens

O JSON Web Token (JWT) é um padrão aberto (RFC 7519) que define uma forma compacta e independente de transmitir com segurança informações entre partes, como um objeto JSON. Essas informações podem ser verificadas e consideradas confiáveis ​​porque são assinadas digitalmente. Os JWTs podem ser assinados usando um segredo (com o algoritmo HMAC) ou um par de chaves pública/privada usando RSA.

Vamos explicar alguns conceitos dessa definição mais adiante.

• Compacto: Devido ao seu tamanho, ele pode ser enviado por meio de uma URL, um parâmetro POST ou dentro de um cabeçalho HTTP. Além disso, devido ao seu tamanho, sua transmissão é rápida.
• Independente: O payload contém todas as informações necessárias sobre o usuário, para evitar consultar o banco de dados mais de uma vez.

Estes são alguns cenários em que os JSON Web Tokens são úteis:

• Autenticação: Este é o cenário típico para o uso do JWT. Assim que o usuário se conectar, cada requisição subsequente incluirá o JWT, permitindo que o usuário acesse rotas, serviços e recursos que são permitidos com aquele token. O Single Sign On é um recurso que hoje utiliza amplamente o JWT, devido ao pequeno overhead e à sua capacidade de ser facilmente utilizado entre sistemas de diferentes domínios.
• Troca de informações: Os JWTs são uma boa maneira de transmitir informações com segurança entre as partes. Como eles podem ser assinados (por exemplo, usando um par de chaves pública/privada), você pode ter certeza de que o remetente é quem diz ser. Além disso, como a assinatura é calculada usando o cabeçalho e o payload, você também pode verificar se o conteúdo não foi alterado.

JWTs consistem em três partes separadas por pontos (.). Elas são:

• Cabeçalho
• Payload
• Assinatura

Portanto, um JWT geralmente se parece com o seguinte.

xxxxx.yyyyy.zzzzz

Vamos analisar as diferentes partes.

Cabeçalho

O cabeçalho normalmente consiste em duas partes: o tipo do token, que é JWT, e o algoritmo de hash, como HMAC SHA256 ou RSA.

Por exemplo:

{
  'alg': 'HS256',
  'typ': 'JWT'
}

Este JSON é codificado em Base64Url para formar a primeira parte do JWT.

Payload

A segunda parte do token é o payload, que contém as claims. Claims são afirmações sobre uma entidade (normalmente, o usuário) e metadados adicionais. Há três tipos de claim: reservada, pública e privada.

• • Claims reservadas: Trata-se de um conjunto de claims predefinidas, que não são obrigatórias, mas recomendadas, além de úteis e interoperáveis. Algumas delas são: iss (emissor), exp (tempo de expiração), sub (assunto), aud (público), entre outras.

Observe que os nomes das claims têm apenas três caracteres, pois o JWT deve ser compacto.

• Claims públicas: Podem ser definidas à vontade por aqueles que usam JWTs. Mas, para evitar colisões, devem ser definidas no IANA JSON Web Token Registry ou como um URI que contém um namespace resistente a colisões.
• Claims privadas: São claims personalizadas criadas para compartilhar informações entre as partes que concordam em usá-las.

Um exemplo de payload pode ser:

{
  'sub': '1234567890',
  'name': 'John Doe',
  'admin': true
}

O payload é então codificado em Base64Url para formar a segunda parte do JWT.

Assinatura

Para criar a parte da assinatura, você deve pegar o cabeçalho codificado, o payload codificado, um segredo, o algoritmo especificado no cabeçalho e assiná-lo.

Por exemplo, se você quiser usar o algoritmo HMAC SHA256, a assinatura será criada da seguinte maneira.

HMACSHA256(
  base64UrlEncode(header) + '.' +
  base64UrlEncode(payload),
  secret)

A assinatura é usada para verificar se o remetente do JWT é quem diz ser e para garantir que a mensagem não foi alterada no caminho.

Unindo tudo

A saída são três strings Base64 separadas por pontos que podem ser facilmente transmitidas em ambientes HTML e HTTP, sendo mais compactas em comparação com padrões baseados em XML, como SAML.

Abaixo está um JWT que tem o cabeçalho anterior e o payload codificados e é assinado com um segredo.

Você pode navegar até jwt.io, onde pode experimentar um JWT e colocar esses conceitos em prática. jwt.io permite decodificar, verificar e gerar JWTs.

Na autenticação, quando o usuário fizer login com sucesso usando suas credenciais, um JSON Web Token será retornado. Como os tokens são credenciais, muito cuidado deve ser tomado para evitar problemas de segurança. Em geral, você não deve manter os tokens por mais tempo do que o necessário.

Você também não deve armazenar dados confidenciais da sessão no armazenamento do navegador devido à falta de segurança.

Sempre que o usuário quiser acessar uma rota protegida, deverá enviar o JWT, normalmente no cabeçalho Autorização, usando o esquema Bearer. Portanto, o conteúdo do cabeçalho deve ser semelhante ao seguinte.

Autorização: Bearer <token>

Esse é um mecanismo de autenticação sem estado, pois o estado do usuário nunca é salvo na memória do servidor. As rotas protegidas do servidor verificarão um JWT válido no cabeçalho de autorização e, se houver, o usuário será permitido. Como os JWTs são independentes, eles contêm todas as informações necessárias, reduzindo a necessidade de voltar a acessar o banco de dados.

Isso permite confiar totalmente em APIs de dados sem estado e até fazer solicitações a serviços downstream. Não importa quais domínios estão servindo suas APIs, pois o Cross-Origin Resource Sharing (CORS) não será um problema, já que não usa cookies.

Vamos falar sobre os benefícios do JSON Web Tokens (JWT) comparando-o com Simple Web Tokens (SWT) e Security Assertion Markup Language Tokens (SAML).

Como o JSON é menos detalhado que o XML, quando é codificado, seu tamanho também é menor; tornando o JWT mais compacto que o SAML. Isso torna o JWT uma boa escolha para ser transmitido em ambientes HTML e HTTP.

Em termos de segurança, o SWT só pode ser assinado simetricamente por um segredo compartilhado usando o algoritmo HMAC. Os tokens JWT e SAML também podem usar um par de chaves pública/privada na forma de um certificado X.509 para assiná-los. No entanto, assinar XML com assinatura digital XML sem introduzir brechas de segurança obscuras é muito difícil em comparação com a simplicidade de assinar JSON.

Os analisadores JSON são comuns na maioria das linguagens de programação, porque mapeiam diretamente para objetos; por outro lado, o XML não tem um mapeamento natural de documento para objeto. Isso torna mais fácil trabalhar com asserções JWT do que SAML.

Em relação ao uso, o JWT é usado em escala de Internet. Isso destaca a facilidade de processamento do lado do cliente de JWTs em várias plataformas, especialmente móveis.

Na Auth0, emitimos JWTs como resultado do processo de autenticação. Quando o usuário faz login usando a Auth0, um JWT é criado, assinado e enviado ao usuário. A Auth0 aceita a assinatura JWT com algoritmos HMAC e RSA. Esse token será usado para autenticar e autorizar com APIs que concederão acesso às suas rotas e recursos protegidos.

Também usamos JWTs para realizar autenticação e autorização na API v2 da Auth0, substituindo o uso tradicional de chaves de API opacas regulares. Com relação à autorização, os JSON Web Tokens proporcionam segurança granular, ou seja, a capacidade de especificar um determinado conjunto de permissões no token, o que melhora a capacidade de depuração.