O que é um token Bearer? Uso, Riscos e Melhores Práticas

A API Scrapeless Scraping usa uma chave de API de conta no cabeçalho x-api-token em vez de autenticação Bearer OAuth, ilustrando que o tipo de credencial e o esquema de apresentação HTTP são escolhas de design separadas.

O que é um token Bearer?

Um token bearer é um token de segurança cuja autoridade é baseada na posse. A palavra “bearer” significa que a parte que carrega o token pode apresentá-lo a um recurso protegido. Ao contrário de um design de prova de posse, um fluxo básico de bearer não exige que o chamador demonstre controle de uma chave criptográfica separada para cada solicitação.

O RFC 6750 define o uso de tokens bearer do OAuth 2.0.Descreve como os clientes enviam tokens de acesso para servidores de recursos, como os servidores retornam desafios de autenticação e erros, e quais ameaças de segurança as implementações devem abordar.

Tokens bearer são comuns em APIs HTTP porque a interação do cliente é simples. O servidor de autorização emite um token de acesso, o cliente o armazena e o cliente o envia com solicitações de API. A simplicidade move a responsabilidade para a segurança do transporte, manuseio de tokens, validação, design de escopo e resposta a incidentes.

Como funciona o cabeçalho de autorização

A apresentação HTTP preferida usa o Authorization cabeçalho de solicitação com o Bearer esquema:

Authorization: Bearer REDACTED

O nome do esquema é insensível a maiúsculas e minúsculas na análise de autenticação HTTP, mas os clientes devem usar a capitalização convencional. O valor do token é opaco para o cliente, a menos que o perfil do token forneça explicitamente ao cliente uma razão para inspecioná-lo. Os clientes não devem tomar decisões de autorização decodificando o conteúdo do token de acesso; o servidor de recursos é o ponto de aplicação.

A solicitação deve usar HTTPS, e o cliente deve validar o certificado do servidor de acordo com seu modelo de confiança de plataforma. O cabeçalho ainda pode vazar através de logs de aplicativos, agentes de rastreamento, proxies de depuração, relatórios de falhas ou extensões do navegador, então cada camada que observa solicitações precisa de regras de redação.

Token Bearer, Token de Acesso e OAuth

Um token de acesso é uma credencial que representa autorização para acessar um recurso. Bearer descreve como esse token é usado. OAuth é a estrutura pela qual um cliente pode obter um token de acesso sob uma concessão. Esses termos estão relacionados, mas não são intercambiáveis.

Tokens de acesso OAuth são frequentemente tokens bearer, mas outro perfil pode vincular um token a uma chave mantida pelo cliente. Um sistema não OAuth também pode inventar um token no estilo bearer, embora usar o esquema padrão sem seguir a segurança e a semântica de erro associadas crie confusão.

Um código de autorização não é um token de acesso bearer para APIs de recursos. É uma credencial intermediária de curta duração trocada no ponto final de token do servidor de autorização. Um token de atualização também não é enviado para servidores de recursos ordinários; é usado com o servidor de autorização para continuar uma concessão existente.

Token Bearer vs Chave de API vs JWT

Um JWT pode ser um token de portador, mas nem todo JWT é um token de acesso e nem todo token de portador é um JWT. Um JWT assinado comprova que um emissor aprovado protegeu as alegações contra alteração; não prova que o apresentador é o detentor pretendido, a menos que o perfil adicione vinculação do remetente.

Tokens de Portador Opacos e Autocontidos

Tokens Opacos

Um token opaco é um valor imprevisível cujo significado é mantido pela infraestrutura de autorização. O servidor de recursos pode chamar um endpoint de introspecção, usar um armazenamento de tokens compartilhado ou confiar em um gateway que resolve o token. A pesquisa central pode refletir revogação e mudanças de política rapidamente, mas acrescenta decisões sobre disponibilidade, latência e cache.

Tokens Autocontidos

Um token autocontido carrega alegações que um servidor de recursos pode validar localmente. O JWT é uma representação comum. O servidor verifica a assinatura ou o código de autenticação de mensagem sob um perfil rigoroso e depois verifica emissor, público, tempo, tipo de token, escopo e quaisquer alegações de confirmação necessárias.

O RFC 8725 fornece as melhores práticas atuais de segurança para JWT.Ele alerta contra confusão de algoritmo, validação fraca, confusão entre JWTs, e confiança cega em alegações recebidas. Um servidor de recursos deve configurar algoritmos permitidos e perfis de token esperados em vez de aceitar o que quer que o cabeçalho do token solicite.

O que um Servidor de Recursos Deve Validar

• Integridade ou status ativo do token. Valide a assinatura sob um algoritmo permitido ou resolva o token opaco através do sistema de autorização confiável.
• Emissor. Aceite tokens apenas do servidor de autorização configurado para este recurso.
• Público. Confirme que o token foi emitido para esta API ou conjunto de recursos.
• Vida útil. Imponha a expiração e qualquer condição de não antes com uma pequena tolerância documentada de relógio.
• Perfil e tipo de token. Evite que um token de ID, código de autorização ou token de outro contexto de protocolo seja aceito como um token de acesso à API.
• Escopo ou alegações de autorização. Confirme que o token permite a operação solicitada.
• Política em nível de recurso. Verifique inquilino, propriedade, função, estado do objeto e outras regras de domínio mesmo quando o token tiver um escopo amplo.

Uma assinatura válida é apenas uma verificação. Ela prova que o token foi protegido por uma chave confiável sob o algoritmo aceito. Não prova que o token tem como alvo esta API, é atual, tem a autoridade requerida ou pode acessar este registro específico.

Riscos de Segurança de Token de Portador

O risco central é a divulgação do token. Um token de portador copiado pode ser usado até expirar, ser revogado ou ser rejeitado por outro controle de política. A exposição pode ocorrer através de URLs, logs de aplicação, capturas de tela de suporte, armazenamento de navegador, cabeçalhos de referência, rastros de proxy, controle de versão ou dispositivos de cliente comprometidos.

URLs são particularmente perigosas. Strings de consulta aparecem nos logs de acesso do servidor web, histórico do navegador, sistemas de análise e links copiados. O RFC 6750 define um método de corpo codificado em formulário sob condições restritas e documenta o uso de consulta URI para compatibilidade, mas novos clientes devem usar o cabeçalho de Autorização.

Cross-site scripting pode expor tokens acessíveis pelo navegador. Manter um token de portador de longa duração no armazenamento local o torna disponível para scripts maliciosos executando na mesma origem. As arquiteturas de navegador devem minimizar a exposição do token ao JavaScript, usar vidas úteis de acesso curtas, impor uma política de segurança de conteúdo forte e considerar um padrão de backend-para-frontend quando apropriado.

Armazenamento de Token por Tipo de Cliente

Um serviço de backend armazena tokens na memória do lado do servidor ou em um armazenamento de credenciais protegido aprovado e limita o acesso à identidade de carga de trabalho que precisa deles. Os tokens não devem ser gravados em caches de disco, despejos de ambiente ou logs gerais sem uma razão revisada e modelo de proteção.

Uma aplicação instalada usa armazenamento seguro do sistema operacional onde disponível. Um cliente de navegador tem um ambiente mais exposto e deve manter a vida útil do token e o acesso ao script o menor possível. Um cookie de sessão não é automaticamente mais seguro; os designs de cookie precisam de controles Secure, HttpOnly, SameSite, de falsificação de solicitação entre sites e de política de sessão do lado do servidor.

Nenhuma escolha de armazenamento corrige um token poderoso demais. Mantenha escopos estreitos, públicos específicos, vidas úteis curtas e recursos protegidos por autorização do lado do servidor.

Alternativas com Restrições de Remetente

Um token com restrição de remetente exige que o apresentador comprove a posse de uma chave separada, reduzindo o valor de uma string de token roubada. Demonstrar Prova de Posse, ou DPoP, vincula tokens OAuth a uma chave de aplicação através de provas assinadas anexadas a requisições.

O RFC 9449 define OAuth DPoP.A TLS Mútua é outra abordagem que restringe o remetente para ambientes de cliente confidencial adequados. Esses designs adicionam requisitos de geração de chave, armazenamento, detecção de repetição e interoperabilidade, portanto, devem ser selecionados sob um modelo de ameaça claro.

Expiração, Revogação e Introspecção

Tokens de acesso de curta duração limitam o tempo que um token revelado permanece útil. O cliente pode obter novo acesso através de uma sessão autorizada ou processo de token de atualização. A credencial de atualização merece proteção mais forte porque pode estender o acesso além da vida útil de um token de acesso.

Tokens opacos podem refletir revogação através de introspecção ou pesquisa central. Tokens autocontidos são frequentemente aceitos até a expiração, a menos que o servidor de recursos verifique um estado de revogação ou sessão. O design certo equilibra mudanças de política imediatas, latência, disponibilidade, cache e risco.

Semântica de logout deve ser definida. Encerrar uma sessão de cliente local, revogar um token de atualização, revogar um token de acesso e encerrar uma sessão do servidor de autorização são operações diferentes. Uma interface de usuário deve descrever o que realmente invalida.

Casos de Uso Comuns de Token de Portador

Lista de Verificação de Token Bearer

1. Envie tokens apenas por HTTPS. Valide o servidor pretendido e mantenha tokens fora das URLs.
2. Use o cabeçalho Authorization. Siga o esquema documentado da API e não invente um posicionamento alternativo.
3. Emita autoridade restrita. Limite o público, escopo, duração, locatário e permissões de recurso.
4. Valide o perfil completo do token. A assinatura sozinha é insuficiente.
5. Oculte antes da exportação de observabilidade. Cubra cabeçalhos, rastros, exceções, dumps de requisições e ferramentas de suporte.
6. Proteja o armazenamento para o tipo de cliente. Clientes públicos e confidenciais têm capacidades diferentes.
7. Planeje revogação e resposta a incidentes. Saiba quais tokens, concessões e sessões podem ser desativados e com que rapidez os servidores de recursos observam a mudança.

Conclusão

Um token bearer é poderoso porque torna chamadas de API autorizadas simples: apresente o token e o servidor de recursos avalia sua autoridade. A mesma propriedade torna a divulgação séria. Sistemas de token bearer seguros usam TLS, o cabeçalho Authorization, validação rigorosa de perfil de token, públicos e escopos restritos, durações curtas, armazenamento protegido, redação agressiva e controles de revogação. Quando o risco de roubo exige uma garantia mais forte, tokens com restrições de remetente adicionam provas vinculadas a uma chave mantida pelo cliente.