Português (Portugal)

oidc
oauth
jwt
token opaco

Token opaco vs JWT

Compreender as diferenças entre tokens opacos e JWTs, os seus casos de uso e como são validados em sistemas baseados em OIDC.

Simeng

Developer

8/30/2024

Pare de perder semanas com autenticação de utilizadores

Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores em minutos e concentre-se no seu produto principal.

Começar

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:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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.

O cliente solicita um token de acesso ao servidor de autorização.
O servidor de autorização emite um token opaco.
O cliente envia a requisição de acesso ao recurso com o token opaco no cabeçalho.
O provedor de recursos envia uma solicitação introspectiva de token para o servidor de autorização para validar o token.
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.

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.
O cliente solicita um token de acesso ao servidor de autorização.
O servidor de autorização emite um token JWT.
O cliente envia a requisição de acesso ao recurso com o token JWT no cabeçalho.
O provedor de recursos decodifica e valida o token JWT usando a chave pública obtida do servidor de autorização.
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

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.

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

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.

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:

Experimente o Logto hoje

O que é um token opaco?#

O que é um JWT?#

Validação do token de acesso opaco#

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

Casos de uso no OIDC#

Tokens opacos#

JWTs#

Conclusão#

O que é um token opaco?#

O que é um JWT?#

Validação do token de acesso opaco#

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

Casos de uso no OIDC#

Tokens opacos#

JWTs#

Conclusão#

O que é um token opaco?

O que é um JWT?

Validação do token de acesso opaco

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

Casos de uso no OIDC

Tokens opacos

JWTs

Conclusão

O que é um token opaco?

O que é um JWT?

Validação do token de acesso opaco

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

Casos de uso no OIDC

Tokens opacos

JWTs

Conclusão