Token opaco vs JWT

No Logto, como uma plataforma abrangente de CIAM baseada em OIDC, os tokens de autorização desempenham um papel crucial na segurança das interações dos usuários e no gerenciamento de acesso aos recursos. Entre os vários tipos de tokens usados para autorização, os tokens opacos e JWTs (Tokens Web JSON) são os mais importantes.

Recebemos várias perguntas de nossa comunidade, como: Qual é a diferença entre um token opaco e um JWT? Por que não consigo decodificar o token de acesso que recebi e por que o comprimento do token parece curto? Este post do blog tem como objetivo esclarecer esses conceitos e ajudar você a entender as distinções entre tokens opacos e JWTs, seus casos de uso e por que você pode encontrar comportamentos diferentes ao trabalhar com eles.

O que é um token opaco?#

Um token opaco é um tipo de token de acesso que, como o nome sugere, é opaco ou não transparente para o cliente ou qualquer parte externa. Isso significa que o próprio token não carrega nenhuma informação legível sobre o usuário ou a autorização concedida.

Quando você recebe um token opaco, ele geralmente aparece como uma sequência aparentemente aleatória de caracteres, e tentar decodificá-lo não resultará em dados significativos.

Aqui está um exemplo de um token opaco:

Como o conteúdo real do token é conhecido apenas pelo servidor de autorização que o emitiu, para validar um token opaco, o cliente deve enviá-lo de volta ao servidor, que então verifica sua autenticidade e determina as permissões associadas. Essa abordagem garante que informações sensíveis permaneçam ocultas, proporcionando uma camada extra de segurança, mas também requer comunicação adicional com o servidor para validar o token.

Prós:

• seguro: Tokens opacos não expõem nenhuma informação sensível para o cliente. O conteúdo do token é conhecido apenas pelo servidor de autorização.
• revogável: Como o token é armazenado no servidor, e a única maneira de validá-lo é através do ponto de introspecção no servidor de autorização, o servidor pode facilmente revogar o token se necessário e impedir o acesso não autorizado.
• tamanho pequeno: Tokens opacos são tipicamente mais curtos que JWTs, o que pode ser benéfico para considerações de desempenho e armazenamento.

Contras:

• com estado: Tokens opacos exigem que o servidor de autorização mantenha estado para validar o token, o que pode introduzir complexidade adicional e sobrecarga.
• desempenho: A necessidade de comunicação adicional com o servidor para validar o token pode impactar o desempenho, especialmente em cenários de alto tráfego.

O que é um JWT?#

Em contraste com tokens opacos, um JWT (Token Web JSON) é um token auto-suficiente, sem estado, que transporta informações em um formato estruturado e legível.

Um JWT é composto por três partes: um header, um payload e uma signature, cada um codificado em Base64URL.

Aqui está um exemplo de um JWT:

• O header contém informações sobre o tipo de token e o algoritmo usado para assinar. Por exemplo, {"alg": "HS256", "typ": "JWT"}.
• A seção payload contém claims—pedaços de informações sobre o usuário ou a autorização—tais como ID do usuário, tempo de expiração e escopos. Como esses dados são codificados mas não criptografados, qualquer pessoa que tenha o token pode decodificá-lo para ver as claims, embora não possam alterá-lo sem invalidar a assinatura. Com base na especificação e configuração do servidor de autorização, várias claims podem ser incluídas no payload. Isso dá ao token sua natureza auto-suficiente. Por exemplo, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• A signature é gerada combinando o header, payload e uma chave secreta usando o algoritmo especificado. Essa assinatura é usada para verificar a integridade do token e garantir que não foi adulterada.

Os JWTs são comumente usados porque podem ser verificados localmente pelo cliente ou qualquer serviço, sem a necessidade de interagir com o servidor de autorização. Isso torna os JWTs particularmente eficientes para sistemas distribuídos, onde múltiplos serviços podem precisar verificar a autenticidade do token de forma independente.

No entanto, essa conveniência também vem com a responsabilidade de garantir que as claims do token não sejam excessivamente expostas, já que são visíveis para qualquer pessoa que tenha acesso ao token. Além disso, os JWTs são tipicamente de curta duração, e o tempo de expiração é incluído nas claims do token para garantir que o token não seja válido indefinidamente.

Prós:

• sem estado: Os JWTs são auto-suficientes e não requerem estado no servidor para validar.
• compatibilidade entre serviços: Os JWTs podem ser facilmente compartilhados e verificados em diferentes serviços, tornando-os ideais para sistemas distribuídos.
• extensível: O payload de um JWT pode conter claims personalizadas, permitindo autorização flexível e compartilhamento de informações.
• padrão: Tokens JWT seguem um padrão bem definido (RFC 7519), tornando-os amplamente suportados e interoperáveis.

Contras:

• exposição: As claims em um JWT são visíveis para qualquer pessoa que tenha acesso ao token, então informações sensíveis não devem ser incluídas no payload.
• tamanho grande: Os JWTs podem ser maiores que tokens opacos devido às informações adicionais que carregam, o que pode impactar desempenho e considerações de armazenamento. As claims em um token JWT devem ser mantidas ao mínimo para reduzir o tamanho do token.
• complexidade de revogação: Como os JWTs são sem estado, são tipicamente válidos por um curto período de tempo, e não há mecanismo embutido para revogar tokens antes de expirarem, o que significa que um token comprometido pode permanecer válido até que expire.

Validação de token de acesso opaco#

Um token de acesso opaco é validado enviando-o de volta ao servidor de autorização para verificação. O servidor de autorização mantém o estado dos tokens emitidos e pode determinar a validade do token com base em seu armazenamento interno.

1. O cliente solicita um token de acesso ao servidor de autorização.
2. O servidor de autorização emite um token opaco.
3. O cliente envia a solicitação de acesso ao recurso com o token opaco no cabeçalho.
4. O provedor de recursos envia uma solicitação de introspecção de token ao servidor de autorização para validar o token.
5. O servidor de autorização responde com as informações do token.

Validação de token de acesso JWT (offline)#

Um token de acesso JWT pode ser validado offline pelo cliente ou qualquer serviço que tenha acesso à chave pública do token.

0. O provedor de recursos pré-busca a chave pública do servidor de autorização do endpoint de descoberta OIDC. A chave pública é usada para verificar a assinatura do token e garantir sua integridade.
1. O cliente solicita um token de acesso ao servidor de autorização.
2. O servidor de autorização emite um token JWT.
3. O cliente envia a solicitação de acesso ao recurso com o token JWT no cabeçalho.
4. O provedor de recursos decodifica e valida o token JWT usando a chave pública obtida do servidor de autorização.
5. O provedor de recursos concede acesso com base na validade do token.

Casos de uso no OIDC#

No contexto do OIDC (OpenID Connect), tokens opacos e JWTs servem a diferentes propósitos e são usados em cenários distintos.

Tokens opacos#

1. Recuperação de perfil de usuário:

Por padrão, quando um cliente solicita um token de acesso sem especificar um recurso e inclui o escopo openid, o servidor de autorização emite um token de acesso opaco. Este token é usado principalmente para recuperar informações de perfil de usuário do endpoint OIDC /oidc/userinfo. Ao receber uma solicitação com o token de acesso opaco, o servidor de autorização verifica seu armazenamento interno para recuperar as informações de autorização associadas e verifica a validade do token antes de responder com os detalhes do perfil do usuário.

2. Troca de token de atualização:

Tokens de atualização são projetados para serem trocados apenas entre o cliente e o servidor de autorização, sem a necessidade de serem compartilhados com provedores de recursos. Como tal, tokens de atualização são tipicamente emitidos como tokens opacos. Quando o token de acesso atual expira, o cliente pode usar o token de atualização opaco para obter um novo token de acesso, garantindo acesso contínuo sem reautenticar o usuário.

JWTs#

1. Token ID:

No OIDC, o token ID é um JWT que contém informações do usuário e é usado para autenticar o usuário. Tipicamente emitido ao lado do token de acesso, o token ID permite ao cliente verificar a identidade do usuário. Por exemplo:

O cliente pode validar o token ID para garantir a identidade do usuário e extrair informações do usuário para personalização ou propósitos de autorização. O token ID é para uso único e não deve ser usado para autorização de recursos de API.

2. Acesso a recursos de API:

Quando um cliente solicita um token de acesso com um indicador de recurso específico, o servidor de autorização emite um token de acesso JWT destinado ao acesso a esse recurso. O JWT contém claims que o provedor de recursos pode usar para autorizar o acesso do cliente. Por exemplo:

O provedor de recursos pode validar a solicitação verificando as claims:

• iss: Confirma que o token foi emitido por um servidor de autorização confiável.
• sub: Identifica o usuário associado ao token.
• aud: Garante que o token é destinado ao recurso específico.
• scope: Verifica as permissões concedidas ao usuário.

Conclusão#

Em resumo, tokens opacos e JWTs servem a diferentes propósitos em sistemas baseados em OIDC, com tokens opacos proporcionando uma abordagem segura e com estado para autorização e JWTs oferecendo uma alternativa auto-suficiente e sem estado. Entender as distinções entre esses tipos de tokens e seus casos de uso é essencial para projetar mecanismos de autenticação e autorização seguros e eficientes em suas aplicações.

Descubra mais recursos de token de acesso no Logto:

• Use RBAC para proteger sua API
• Token de acesso de organização
• Claims personalizadas de JWT