oauth 2.0oidc

O que é Token opaco?

Um token opaco é uma string aleatória e única que não tem significado para o cliente, mas serve como uma chave de referência para procurar dados de autorização na base de dados do servidor.

O que é um token opaco?

Um token opaco é uma string aleatória e única que não tem significado para o cliente, mas serve como uma chave de referência para procurar dados de autorização na base de dados do servidor.

Tokens opacos são geralmente gerados usando um Gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) para garantir a sua imprevisibilidade e segurança, e o seu formato é determinado pelo seu issuer (emissor).

Aqui está um exemplo de um token opaco:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Qual é a diferença entre JWT (JSON Web Token) e token opaco?

A principal diferença reside em como esses tokens lidam e validam informações de autorização:

Um token opaco é uma string aleatória que não contém informações em si. O servidor deve consultar a sua base de dados backend para recuperar quaisquer dados de autorização associados a este token. Isso torna os tokens opacos completamente dependentes do authorization server (servidor de autorização) para validação e interpretação.

JWT é um token auto-contido que carrega todas as informações necessárias dentro de si.

Aqui está um exemplo de um JWT, é uma string codificada em base64:

eyJhbGciOiJIUzI1NiIs.eyJzdWIiOiIxMjM0NTY3O.SflKxwRJSMeKKF2QT4f

E contém três partes separadas por pontos:

Header - Contém informações sobre o tipo de token e o algoritmo usado para assinatura. Por exemplo, {"alg": "HS256", "typ": "JWT"}.
Payload - Contém claims (declarações)—informações sobre o utilizador ou a autorização, como ID do utilizador, tempo de expiração e scopes (escopos). Qualquer pessoa pode decodificá-lo para ver as claims porque está codificado, mas não criptografado.
Signature - Gerada combinando o header, payload e uma chave secreta usando o algoritmo especificado. Esta assinatura é usada para verificar a integridade do token e garantir que não foi adulterado.

Esta estrutura permite que os JWTs sejam validados e usados sem consultar uma base de dados.

Para mais informações detalhadas sobre JWTs, por favor consulte JSON Web Token (JWT) .

E confira Token opaco vs JWT para aprender mais sobre as suas diferenças em maior profundidade.

Como validar um token opaco

Em sistemas simples, a validação de tokens opacos é tipicamente tratada diretamente pelo servidor, que consulta a base de dados usando o token opaco como uma chave para recuperar as informações de autorização associadas.

Em sistemas multi-partes que introduzem OAuth 2.0, múltiplos resource servers (servidores de recursos) (ver: Servidor de recursos ) podem precisar validar o mesmo token opaco. OAuth 2.0 fornece um mecanismo padronizado de token introspection (introspecção de token) para esta validação:

Para informações detalhadas sobre token introspection, por favor consulte Introspecção de token (Token introspection) .

Como são usados os tokens opacos no OIDC?

No contexto do OIDC ( OpenID Connect (OIDC) ), os tokens opacos servem propósitos específicos em diferentes cenários:

Recuperação de perfil de utilizador

Por padrão, quando um cliente solicita um access token (token de acesso) sem especificar um recurso e inclui o scope openid, o authorization server emite um access token opaco. Este token é usado principalmente para recuperar informações de perfil de utilizador do endpoint /oidc/userinfo do OIDC (ver: Endpoint de userinfo (userinfo endpoint) ).

Troca de refresh token

Refresh tokens (tokens de atualização) (ver: Token de atualização (Refresh token) ) são tipicamente emitidos como tokens opacos, uma vez que são apenas trocados entre o cliente e o authorization server. Quando o access token atual expira, o cliente pode usar o refresh token opaco para obter um novo access token sem re-autenticar o utilizador.

Quais são os prós e contras do token opaco?

Prós

Segurança: Tokens opacos são perfeitos para lidar com dados sensíveis como refresh tokens. Como o conteúdo é completamente aleatório e sem significado, mesmo que alguém intercepte o token, não poderá extrair nenhuma informação útil. Isso torna-os especialmente valiosos em cenários de alta segurança, como transações bancárias ou manipulação de dados sensíveis de utilizadores.
Revogabilidade: O servidor pode invalidar imediatamente um token opaco a qualquer momento. Isso é particularmente útil quando é necessário remover rapidamente o acesso de um utilizador. Ao contrário dos JWTs que permanecem válidos até expirarem, os tokens opacos podem ser revogados instantaneamente (ver: Limitações do JWT ).
Tamanho: Tokens opacos são tipicamente muito mais curtos do que JWTs. Este tamanho reduzido diminui o uso de largura de banda de rede e requisitos de armazenamento. O benefício torna-se particularmente notável em sistemas que transmitem tokens frequentemente, como aplicações móveis ou dispositivos IoT.
Simplicidade: A implementação de tokens opacos é direta. Você gera uma string aleatória e armazena-a com os seus dados associados. Não há necessidade de lidar com criptografia complexa ou verificação de assinatura como com JWTs. Esta simplicidade torna-os ideais para autenticação de sistemas internos.

Contras

Stateful: Cada token opaco requer armazenamento no lado do servidor. Isso cria complexidade adicional em sistemas distribuídos porque os dados do token devem ser sincronizados entre múltiplos servidores. Por exemplo, se você tiver múltiplos authentication servers, todos eles precisam de acesso à mesma base de dados de tokens ou sistema de cache para validar tokens corretamente.
Desempenho: A validação de tokens sempre requer uma consulta à base de dados ou chamada de API. Em sistemas de alto tráfego, essas consultas adicionais à base de dados podem criar gargalos de desempenho. Por exemplo, se o seu sistema lida com milhares de pedidos por segundo, cada um requerendo validação de token, a carga adicional na base de dados torna-se significativa.
Interoperabilidade: Diferentes sistemas podem implementar tokens opacos de maneiras diferentes. Isso pode causar desafios de integração ao trabalhar com serviços de terceiros ou diferentes authorization servers. Embora padrões como a introspecção de tokens do OAuth 2.0 ajudem, você ainda pode encontrar problemas de compatibilidade quando sistemas usam diferentes formatos de token ou métodos de validação.