Token opaco vs JWT

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

Recebemos várias perguntas da nossa comunidade, tais 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? Esta publicação no blog visa esclarecer estes conceitos e ajudá-lo a compreender as distinções entre tokens opacos e JWTs, os seus casos de uso e por que pode encontrar diferentes comportamentos ao trabalhar com eles.

O que é um token opaco?#

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

Quando você recebe um token opaco, ele geralmente aparece como uma sequência de caracteres aparentemente aleatória, e tentar decodificá-lo não produzirá 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 para o servidor, que então verifica a sua autenticidade e determina as permissões associadas. Esta abordagem assegura que informações sensíveis permanecem ocultas, fornecendo uma camada adicional de segurança, mas também requer comunicação adicional com o servidor para validar o token.

Prós:

• seguro: Os tokens opacos não expõem qualquer informação sensível ao cliente. O conteúdo do token é conhecido somente pelo servidor de autorização.
• revogável: Como o token é armazenado no servidor e a única forma 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 prevenir acesso não autorizado.
• tamanho pequeno: Os tokens opacos são tipicamente mais curtos do que os JWTs, o que pode ser benéfico para considerações de desempenho e armazenamento.

Contras:

• com estado: Os tokens opacos requerem que o servidor de autorização mantenha estado para validar o token, o que pode introduzir complexidade e sobrecarga adicionais.
• 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 os tokens opacos, um JWT (JSON Web Token) é um token autocontido, sem estado, que transporta informações de forma estruturada e legível.

Um JWT é composto por três partes: um header (cabeçalho), um payload (carga útil) e uma signature (assinatura), cada uma codificada 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 utilizador ou a autorização — tais como ID do utilizador, tempo de expiração e escopos. Como esses dados são codificados, mas não encriptados, qualquer pessoa que possua o token pode decodificá-lo para ver as claims, embora não possa alterá-lo sem invalidar a assinatura. Baseado na especificação e configuração do servidor de autorização, várias claims podem ser incluídas na carga útil. Isso dá ao token sua natureza autocontida. Por exemplo, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• A signature é gerada combinando o cabeçalho, a carga útil e uma chave secreta usando o algoritmo especificado. Esta assinatura é usada para verificar a integridade do token e garantir que não foi adulterado.

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. Isto 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, esta conveniência também vem com a responsabilidade de garantir que as claims do token não sejam expostas excessivamente, pois são visíveis a 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 está 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 autocontidos e não requerem estado no servidor para serem validados.
• compatibilidade entre serviços: Os JWTs podem ser facilmente compartilhados e verificados entre diferentes serviços, tornando-os ideais para sistemas distribuídos.
• extensível: A carga útil de um JWT pode conter claims personalizadas, permitindo uma autorização e compartilhamento de informações flexíveis.
• 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, portanto, informações sensíveis não devem ser incluídas na carga útil.
• tamanho grande: Os JWTs podem ser maiores do que os tokens opacos devido às informações adicionais que transportam, o que pode impactar considerações de desempenho e armazenamento. As claims em tokens JWT devem ser mantidas ao mínimo para reduzir o tamanho do token.
• complexidade de revogação: Como os JWTs são sem estado, eles são tipicamente válidos por um curto período de tempo, e não há um mecanismo embutido para revogação de tokens antes que expirem, o que significa que um token comprometido pode continuar válido até que expire.

Validação do token de acesso opaco#

Um token de acesso opaco é validado enviando-o de volta para o 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 requisição de acesso ao recurso com o token opaco no cabeçalho.
4. O provedor de recursos envia uma solicitação introspectiva de token para o servidor de autorização para validar o token.
5. O servidor de autorização responde com as informações do token.

Validação do 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 a partir do ponto 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 requisiçã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), os 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 utilizador:

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 do perfil do utilizador a partir 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 utilizador.

2. Troca de token de atualização:

Os tokens de atualização são projetados para serem trocados apenas entre o cliente e o servidor de autorização, sem precisar ser compartilhados com provedores de recursos. Assim, os 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 re-autenticar o utilizador.

JWTs#

1. Token de identificação:

No OIDC, o token de identificação é um JWT que contém informações do utilizador e é usado para autenticar o utilizador. Normalmente emitido juntamente com o token de acesso, o token de identificação permite que o cliente verifique a identidade do utilizador. Por exemplo:

O cliente pode validar o token de identificação para garantir a identidade do utilizador e extrair informações do utilizador para personalização ou propósitos de autorização. O token de identificação é 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 a acessar 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 utilizador associado ao token.
• aud: Assegura que o token é destinado ao recurso específico.
• scope: Verifica as permissões concedidas ao utilizador.

Conclusão#

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

Descubra mais funcionalidades de tokens de acesso no Logto:

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