Descobre o que são tokens bearer, como funcionam no OAuth 2.0 e JWT, a diferença face aos access tokens e as melhores práticas.
Por trás de quase todos os logins de apps modernas ou pedidos API está um trabalhador silencioso: o token bearer. Podes não reparar, mas está lá sempre que conectas serviços, fazes login ou buscas dados na cloud.
Este guia explica o que fazem os tokens bearer, porque são importantes e como usá-los de forma segura.
Um token bearer é um pedaço de dados, normalmente uma cadeia de caracteres, que prova que o portador tem autorização para aceder a um recurso. O ponto importante é que quem porta o token pode usá-lo, sem precisar dar mais provas.
Pensa num cartão de embarque de avião. Depois de o teres na mão, podes passar pela segurança e embarcar. Ninguém te pede novamente identificação se o cartão for válido. Da mesma forma, um token bearer permite à tua aplicação "embarcar na API" sem voltar a verificar a tua identidade em cada pedido.
Por exemplo, depois de fazeres login no Spotify no telemóvel, não precisas de introduzir a palavra-passe sempre que quiseres ouvir música. Em vez disso, a app guarda um token bearer que informa os servidores do Spotify: "este pedido é de um utilizador autorizado".
O fluxo dos tokens bearer pode ser dividido em alguns passos:
O utilizador faz login
Imagina que fazes login numa app bancária com nome de utilizador e palavra-passe.
O fornecedor de identidade gera um token
Assim que validado, o servidor de autenticação devolve um token bearer. Pode ser, por exemplo:
O cliente usa o token
Sempre que tocas em “Ver Saldo” ou “Transferir Dinheiro”, a app inclui o token no pedido HTTP:
A API valida o token
O servidor verifica se o token ainda é válido, se não expirou e se tem as permissões certas (por exemplo, read:balance ou write:transfer).
Acesso concedido
Se tudo estiver certo, o servidor responde com a informação pedida.
Este modelo é muito usado em serviços como as APIs do GitHub, onde os programadores autenticam-se com um token bearer em vez de repetir as credenciais.
Os tokens bearer ganharam popularidade porque resolvem problemas clássicos de segurança na web. Ao contrário das sessões no servidor, não é preciso guardar dados de cada utilizador autenticado. O próprio token já inclui a informação suficiente para o servidor validar o pedido.
Por exemplo, numa arquitetura de microserviços (em que dezenas de serviços comunicam entre si), manter uma base central de sessões seria complexo e pouco eficiente. Com tokens bearer, cada serviço pode validar pedidos de forma independente, tornando o sistema mais leve e escalável.
Exemplo concreto: as APIs do Slack dependem fortemente de tokens bearer. Quando constróis um bot Slack, recebes um token que permite ao bot aceder aos endpoints do Slack sem precisar de manter uma sessão para cada utilizador.
Muitos tokens bearer são implementados como JWTs (JSON Web Tokens). Estes tokens são cadeias codificadas que trazem informações sobre o utilizador e as suas permissões.
Vamos descodificar um JWT de exemplo:
Eis o significado:
sub: O sujeito, ou o ID único do utilizador.name: O nome do utilizador.iat: Data de emissão.exp: Hora de expiração (quando o token deixa de ser válido).scope: As permissões; neste caso, permite à app ler e escrever mensagens.Na prática, se o token da Jane só tivesse o scope read:messages, a app poderia só buscar as mensagens, mas não enviar nenhuma por ela.
É fácil confundir tokens bearer com access tokens, porque os termos aparecem juntos frequentemente. Na verdade, estão relacionados, mas não são a mesma coisa.
Um access token é uma credencial que representa a autorização de um utilizador para aceder a um recurso. Traz informações como:
Pensa nisso como uma autorização escolar assinada pelo diretor. Diz ao professor (API) que podes ir à visita de estudo (usar o recurso).
Por exemplo, ao fazer login num serviço de armazenamento na cloud, o sistema emite um access token com o scope read:files. Esse token diz à API: “Este utilizador pode ler ficheiros, mas não apagá-los.”
Um token bearer é um tipo de access token. O termo bearer descreve como o token é usado: quem o apresenta pode aceder a recursos, sem precisar de mais provas de identidade.
Ou seja:
Existem outros tipos, como holder-of-key tokens, que obrigam o cliente a provar que tem uma chave criptográfica além do token. Os tokens bearer saltam esse passo extra — o que os torna mais simples, mas arriscados se forem roubados.
<token>.Isto significa que, quando vires “access token” em tutoriais OAuth, quase sempre é um bearer token salvo indicação em contrário.
Para clarificar, vamos ver como os tokens bearer se comparam com outros tipos comuns:
Tokens bearer e access tokens não são conceitos opostos — estão relacionados:
Validar um token bearer é o que protege a tua API de acessos não autorizados. Se os teus tokens são JWT, a validação é local e rápida — a API não precisa contactar o emissor sempre.
Usa esta lista ao configurar gateways de API ou middleware.
Assinatura
Verifica a assinatura com o algoritmo dado (ex: RS256). Vai ao endpoint JWKS do emissor, escolhe a chave certa (kid) e faz cache.
Issuer (iss)
O campo iss do token deve bater certo, exatamente, com a URL confiável do emissor (e esquema correto).
Audience (aud)
Garante que o token foi emitido para a tua API. Compara com o identificador (ex: https://api.example.com) ou outra string lógica.
Expiração (exp) e Not-Before (nbf)
Recusa tokens expirados. Respeita nbf (não pode ser usado antes do arranque). Permite desvio de relógio pequeno (p. ex. 30-60 segundos).
Issued-At (iat)
Útil para debugging e para rejeitar tokens antigos em setups restritos.
Tipo de token
Confirma que é um access token. Alguns fornecedores incluem typ: "at+jwt" ou equivalente. Não aceites ID tokens para aceder a APIs.
Scopes / permissões
Lê o scope ou claims específicos do fornecedor (permissões, roles). Garante o menor privilégio possível em cada endpoint.
Subject (sub)
Identificador estável do utilizador ou cliente. Usa para associar recursos e para auditoria.
Replay e revogação (opcional, recomendado)
Para endpoints sensíveis, verifica uma denylist de jti curta, ou garante que existe sessão ativa. Ajuda após logout ou suspeita de ataque.
Como tokens bearer funcionam com "quem tem, usa", devem ser tratados como chaves de casa. Se alguém roubar a tua chave, pode abrir a porta até trocares a fechadura.
Alguns riscos comuns:
Ataques reais já ocorreram quando programadores por acidente colocaram tokens bearer em repositórios públicos do GitHub. Os atacantes podem procurar estes tokens e usá-los logo para aceder sem autorização.
Para usar tokens bearer com segurança, é essencial seguir as melhores práticas. Eis algumas, com exemplos:
Usa sempre HTTPS
Imagina enviares um token por HTTP numa Wi-Fi pública de café. Qualquer pessoa na rede pode copiar o token e fazer login como tu.
Usa access tokens de curta duração
Na maioria das plataformas, os tokens expiram numa hora. Por exemplo, tokens OAuth do Google duram tipicamente uma hora até ser preciso renovar.
Guarda os refresh tokens com cuidado
Um refresh token serve para pedir access tokens sem novo login, mas deve ser guardado em segurança (por exemplo, numa base de dados encriptada no servidor), e não no lado do cliente.
Dá ao token só as permissões estritamente necessárias
Se a app só precisa de ler o calendário do utilizador, não peças permissão para escrever. Assim, se o token for comprometido, o risco reduz-se.
Revoga tokens quando necessário
Muitas apps SaaS permitem ver sessões ativas e revogá-las. O GitHub, por exemplo, permite revogar tokens de acesso pessoais a qualquer momento.
Monitoriza o uso
Fazer log de uso do token pode denunciar atividades suspeitas. Se o mesmo token for usado em Londres e Nova Iorque com minutos de intervalo, é sinal de alerta.
Vale comparar tokens bearer com outras opções populares:
Cookies & Sessões
Sites tradicionais usam sessões num servidor, identificadas por cookie. Resulta bem em browsers, mas menos eficiente para APIs e apps móveis. Por exemplo, login no Facebook desktop foca-se em cookies; nas apps móveis, usa tokens.
API Keys
Uma API key é uma string estática que autentica a app, não o utilizador. Por exemplo, uma app de meteorologia pode usar uma API key para buscar dados, mas isso não diz ao servidor quem pede. Tokens bearer podem transportar dados do utilizador, tornando-os mais versáteis.
Mutual TLS (mTLS)
Alguns sistemas de alta segurança usam certificados tanto no cliente como no servidor. É mais seguro, mas difícil de escalar. Para a maioria das plataformas SaaS, tokens bearer conseguem equilibrar usabilidade e segurança.