Access Token.

Um access token representa a autorizacao que o dono do recurso concedeu a um cliente, limitada a permissoes e audiencias especificas. Em OAuth 2.0 (RFC 6749) e OpenID Connect, os access tokens podem ser opacos — validados chamando o endpoint de introspection do servidor de autorizacao (RFC 7662) — ou JWTs autocontidos validados localmente por assinatura. Sao normalmente enviados no cabecalho Authorization: Bearer conforme a RFC 6750 e devem viajar sobre TLS.

A fraqueza central de um simples token portador (bearer) e que a posse equivale a autoridade: um token roubado do armazenamento do browser, de um log ou de um proxy pode ser reutilizado por qualquer pessoa. Isto impulsionou o surgimento dos tokens vinculados ao emissor (sender-constrained). A RFC 8705 vincula um token ao certificado TLS do cliente (registando o seu hash na claim cnf.x5t#S256), e a RFC 9449 (DPoP) vincula o token a um par de chaves detido pelo cliente, exigindo um novo JWT de prova assinado em cada pedido, de modo que um token reutilizado e inutil sem a chave privada. Os ataques de roubo de tokens — incluindo a reutilizacao de sessao/token vista no Lapsus$ e em varias intrusoes cloud do tipo "pass-the-token" — sao precisamente o que estes mecanismos derrotam.

Boas praticas: tempos de vida curtos (minutos), scopes restritos, validacao rigorosa de audience e issuer, rejeitar o truque de JWT alg: none, combinar com refresh tokens para renovacao e manter os tokens fora do armazenamento acessivel ao JavaScript. Para APIs de alto valor, prefira tokens vinculados por DPoP ou mTLS em vez de simples tokens portadores.

flowchart LR
  RO[Dono do recurso] -->|concede consentimento| AS[Servidor de autorizacao]
  C[Cliente] -->|pedido de token + chave DPoP/mTLS| AS
  AS -->|access token de curta duracao<br/>scope + aud + claim cnf| C
  C -->|Token Bearer + prova de posse| RS[Servidor de recursos / API]
  RS -->|validar assinatura/introspection<br/>verificar aud, exp, vinculo de chave| RS
  RS -->|permitir ou negar| C