Tokens web JSON como blocos de construção para segurança na nuvem

O primeiro rascunho para tokens web JSON já tem mais de 10 anos (é de dezembro de 2010). O rascunho inicial afirma: "O token web JSON (JWT) define um formato de token que pode codificar declarações transferidas entre duas partes. As declarações em um JWT são codificadas como um objeto JSON assinado digitalmente."

Em sua versão mais recente, IETF RFC 7519, foi expandido para o seguinte: "O token web JSON (JWT) é um meio compacto e seguro de URL para representar declarações a serem transferidas entre duas partes. As declarações em um JWT são codificadas como um objeto JSON que é usado como carga útil de uma estrutura JSON Web Signature (JWS) ou como texto simples de uma estrutura JSON Web Encryption (JWE), permitindo que as declarações sejam assinadas digitalmente ou protegidas com integridade com um Código de Autenticação de Mensagem (MAC) e/ou criptografadas com um token."

A nova descrição sugere duas representações de um JWT (muitas vezes pronunciado “jot”) — nomeadamente uma JSON Web Signature (JWS) ou uma estrutura  JSON Web Encryption (JWE) JWS é definido na RFC 7515, JWE na RFC 7516. Existem até mesmo mais algunss padrões de segurança baseados em JSON mais relacionados, todos definidos por um grupo de trabalho chamado JOSE: JSON Object Signing and Encryption.

O OAuth 2.0 é um padrão do setor para autorização. Sem entrar em detalhes, ele oferece um fluxo de autorização e conceitos fundamentais, incluindo o chamado token de acesso e o token de atualização. Não é um requisito usá-los, mas os JWTs são normalmente usados atualmente. Conforme mencionado, o foco do OAuth está na autorização e, às vezes, também é usado de forma inadequada para lidar com a identificação. O OpenID Connect adiciona essa peça que faltava no quebra-cabeça e apresenta a identidade ou token de ID. O token de ID é representado como JWT.

Com esse histórico e alguns padrões como base, como podemos processar o JWT de cima para baixo e quais informações ele contém?

O JWT acima consiste em três partes, cada uma separada por um ponto ('.'):

1. Cabeçalho:: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Carga útil: eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
3. Assinatura: _iVbBcypdse-9sjrxp9iOrGsXKBWrBB3mrHgBtukcfM

Tanto o cabeçalho quanto a carga útil são codificados em base64url e, sem levar em conta possíveis preenchimentos, podem ser decodificados assim:

henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}

henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input

O cabeçalho contém informações sobre o alg(orithm) utilizado — aqui, HS256 (HMAC SHA256). A carga útil depende do tipo de token (access/refresh/ID/…) e é composta por declarações. Esses e outros campos de cabeçalho e carga útil do JOSE predefinidos são gerenciados pela IANA. No exemplo acima, os campos e declarações são subj(ect), name, issued at (iat) e exp(iration time).

A assinatura é calculada aplicando o algoritmo indicado à concatenação do cabeçalho '.' e carga útil e, em seguida, codificar o base64url o resultado. Depois disso, as três partes separadas por um ponto compõem o JWT. Os detalhes de como as assinaturas são derivadas são definidos no RFC 7515.

Você pode acessar o JWT acima neste depurador online em JTW.io. Primeiro, ele mostrará a mensagem "Assinatura inválida". Você pode resolvê-lo substituindo o segredo padrão mostrado por !!!my-really-big-256-bit-secret!!!.

Como o IBM Cloud fornece muitos serviços em seu catálogo e é um aplicativo de internet com muitos componentes próprios, ele faz uso intenso de tokens, incluindo JWTs. Você provavelmente já usou a interface de linha de comando (CLI) do IBM Cloud e o comando ibmcloud IAM oauth-tokens:

Ele imprime os tokens do portador OAuth (tokens de acesso) para a sessão de CLI atual, implementado como JWTs. Esses tokens IAM são usados para acessar serviços de nuvem habilitados para IAM. 

Se você deseja integrar usuários externos à sua conta de nuvem, os JWTs também podem ser usados. Os tokens de identidade e as reivindicações incluídas são trocados para autenticação para identificar o usuário. Muitas soluções utilizam o serviço de segurança IBM Cloud App ID. Ele ajuda a autenticar usuários e proteger recursos. Ele aproveita os padrões mencionados OAuth 2.0 e OpenID Connect e, portanto, lida com tokens de acesso, ID e refresh.

Um dos meus (e dos seus) serviços favoritos é o watsonx Assistant para construir um chatbot. Se você deseja proteger os chats na web (ou seja, proteger ainda mais as mensagens trocadas e certificar a origem das mensagens), os JWTs vêm em seu auxílio.

É claro que há muitos mais exemplos de como os JWTs são utilizados para trocar facilmente declarações (segurança) e, assim, fortalecer a segurança de uma solução em nuvem.

Os JWTs são um meio fácil e autônomo de trocar declarações entre duas partes. São uma estrutura de dados onipresente, na nuvem e no local. Esperamos que o texto acima tenha sido uma introdução útil para despertar seu interesse (se ainda não estivesse!).

Se você quiser examinar e mexer com os JWTs por conta própria, recomendo uma ferramenta on-line como https://jwt.io/ para começar. Se você estiver mais familiarizado com o assunto, use um monitor de rede ou as developer tools em seu navegador para observar os JWTs. Divirta-se e confira nossos tutoriais do IBM Cloud, incluindo muitos tutoriais relacionados a segurança.

Se você tiver feedback, sugestões ou perguntas sobre este post, entre em contato comigo no Twitter (@data_henrik) ou no LinkedIn.