O que é Token opaco?

O que é um token?

Antes de introduzir tokens opacos, é importante entender o que é um token:

Tokens são usados para representar e transmitir informações seguras entre partes, e eles suportam a grande maioria dos processos de Autenticação (Authentication) (autenticação) e Autorização (Authorization) (autorização) que ocorrem na internet nos bastidores. Os dois tipos mais populares de tokens em serviços web são JSON Web Token (JWT) e tokens opacos.

O que é um token opaco?

Tokens opacos são tokens em um formato proprietário que você não pode acessar e tipicamente contêm algum identificador para informações no armazenamento persistente de um servidor.

Um token opaco é uma forma que um token pode assumir, e access tokens (tokens de acesso) e refresh tokens (tokens de atualização) podem existir como tokens opacos. O formato de um token opaco é determinado pelo seu issuer (emissor), e é tipicamente uma sequência de números e/ou caracteres usada para ajudar o issuer (emissor) a recuperar e identificar certas informações em um banco de dados. Aqui está um exemplo de um token opaco:

M-oxIny1RfaFbmjMX54L8Pl-KQEPeQvF6awzjWFA3iq

Por outro lado, JWT é outro formato comum de token. É uma string JSON que contém todas as claims (declarações) e informações, juntamente com uma assinatura do issuer (emissor). Por padrão, não é criptografado, embora possa ser criptografado usando o padrão JSON Web Encryption (JWE) . Mesmo que JWT tipicamente não seja criptografado, isso não compromete sua segurança — a presença da assinatura garante a integridade do conteúdo do token, permitindo total confiança nos dados dentro do JWT.

Ao contrário do JWT, que contém todas as informações necessárias para ser validado diretamente no recurso protegido, tokens opacos não podem ser validados diretamente pelo recurso. Em vez disso, eles requerem validação pelo issuer (emissor) do token opaco (geralmente o Servidor de autorização ). Este processo de validação é tipicamente referido como Introspecção de token (Token introspection) .

O que é JWT?

Em contraste com tokens opacos, um JWT é um token autônomo, sem estado, que carrega 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:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• O header contém informações sobre o tipo de token e o algoritmo usado para assinatura. Por exemplo, {"alg": "HS256", "typ": "JWT"}.
• A seção payload contém claims (declarações) — pedaços de informação sobre o usuário ou a autorização — como ID do usuário, tempo de expiração e scopes (escopos). Como esses dados são codificados, mas não criptografados, qualquer pessoa que tenha o token pode decodificá-lo para ver as claims (declarações), embora não possam alterá-lo sem invalidar a assinatura. Com base na especificação e configuração do authorization server (servidor de autorização), várias claims (declarações) podem ser incluídas no payload. Isso dá ao token sua natureza autônoma. Por exemplo, {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• A 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 ele não foi adulterado.

JWTs são comumente usados porque podem ser verificados localmente pelo cliente ou qualquer serviço, sem a necessidade de interagir com o authorization server (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 (declarações) do token não sejam excessivamente expostas, pois 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 (declarações) do token para garantir que o token não seja válido indefinidamente.

Validação de token de acesso opaco

Um token de acesso opaco é validado enviando-o de volta ao authorization server (servidor de autorização) para verificação. O authorization server (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 access token (token de acesso) ao authorization server (servidor de autorização).
2. O authorization server (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 resource provider (provedor de recursos) envia uma solicitação de introspecção de token ao authorization server (servidor de autorização) para validar o token.
5. O authorization server (servidor de autorização) responde com as informações do token.

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

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

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

Casos de uso no OIDC

No contexto do OIDC ( OpenID Connect (OIDC) ), 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 access token (token de acesso) sem especificar um recurso e inclui o scope (escopo) openid, o authorization server (servidor de autorização) emite um access token (token de acesso) opaco. Este token é usado principalmente para recuperar informações de perfil de usuário do endpoint /oidc/userinfo do OIDC. Ao receber uma solicitação com o access token (token de acesso) opaco, o authorization server (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 refresh token (token de atualização):

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

JWTs

1. ID token:

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

// Payload decodificado de um ID token
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "client_id",
  "exp": 1630368000,
  "name": "John Doe",
  "email": "[email protected]",
  "picture": "<https://example.com/johndoe.jpg>"
}

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

2. Acesso a recursos de API (usando access token):

Quando um cliente solicita um access token (token de acesso) com um Indicador de recurso (Resource indicator) específico, o authorization server (servidor de autorização) emite um access token (token de acesso) JWT destinado ao acesso a esse recurso. O JWT contém claims (declarações) que o resource provider (provedor de recursos) pode usar para autorizar o acesso do cliente. Por exemplo:

// Payload decodificado de um access token JWT
{
  "iss": "<https://auth.wiki>",
  "sub": "1234567890",
  "aud": "<https://api.example.com>",
  "scope": "read write",
  "exp": 1630368000
}

O resource provider (provedor de recursos) pode validar a solicitação verificando as claims (declarações):

• iss: Confirma que o token foi emitido por um authorization server (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.

Veja também

• JSON Web Token (JWT)