O que são tokens bearer?

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.

O que é um token bearer?#

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".

Como funcionam tokens bearer na prática#

O fluxo dos tokens bearer pode ser dividido em alguns passos:

1. O utilizador faz login

   Imagina que fazes login numa app bancária com nome de utilizador e palavra-passe.

2. O fornecedor de identidade gera um token

   Assim que validado, o servidor de autenticação devolve um token bearer. Pode ser, por exemplo:

3. O cliente usa o token

   Sempre que tocas em “Ver Saldo” ou “Transferir Dinheiro”, a app inclui o token no pedido HTTP:

4. 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).

5. 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.

Porque é que os tokens bearer se tornaram populares#

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.

O que está dentro de um token bearer?#

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.

Tokens bearer vs. access tokens: Qual a diferença?#

É 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.

Access token: O “autorização”#

Um access token é uma credencial que representa a autorização de um utilizador para aceder a um recurso. Traz informações como:

• Quem é o utilizador (ID)
• O que pode fazer (permissões/scopes)
• Quando expira

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.”

Token bearer: O “formato de entrega”#

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:

• Todos os tokens bearer são access tokens.
• Mas nem todos os access tokens têm de ser bearer tokens.

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.

Exemplo prático#

• Access token (genérico): Pode ser um dado assinado, às vezes requerendo que o cliente também prove que tem uma chave privada.
• Bearer token (específico): A maioria das implementações de OAuth 2.0 hoje emite access tokens em formato bearer. Por exemplo, o OAuth do Google retorna um access token que usas no cabeçalho Authorization: Bearer <token>.

Isto significa que, quando vires “access token” em tutoriais OAuth, quase sempre é um bearer token salvo indicação em contrário.

Outros tipos de token comparados#

Para clarificar, vamos ver como os tokens bearer se comparam com outros tipos comuns:

• Refresh token: Usado para pedir novo access token quando o antigo expira. Normalmente não são bearer tokens, porque são trocados de forma segura com o servidor de autorização e não usados diretamente nas APIs.
• ID token: Usado para autenticação, não autorização. Traz dados de identidade (ex: email, nome, ID). Pode, dependendo do sistema, também ser um bearer token, mas o objetivo é diferente de um access token.
• API key: Um método mais simples que identifica a app chamada. Na prática, muitas API keys funcionam como bearer tokens — quem tem a chave pode usar a API.

Tokens bearer e access tokens não são conceitos opostos — estão relacionados:

• A maioria dos access tokens são bearer tokens.
• Bearer token descreve como o token é usado (apresentar para aceder).
• No dia-a-dia, os termos “access token” e “bearer token” são usados como sinónimos, apesar das diferenças técnicas.

Como validar um JWT access token (Bearer token)#

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.

A ideia central#

1. Analisa o token.
2. Verifica a assinatura com a chave pública do emissor.
3. Valida campos padrão como issuer, público, validade, not-before.
4. Aplica as regras da app: scopes, roles, tipo de token.
5. Opcionalmente consulta listas de revogação ou estado de sessão em ações de maior risco.

Lista de verificação de validação (JWT)#

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.

Riscos de segurança dos tokens bearer#

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:

• Roubo de token – Se um hacker aceder ao localStorage do browser com o token, pode fazer-se passar pelo utilizador. Por exemplo, em 2018, algumas extensões de browser foram apanhadas a roubar tokens do localStorage para os vender.
• Replay attacks – Um atacante que intercepte o token pode reutilizá-lo até expirar. Sem HTTPS é surpreendentemente fácil.
• Tokens de longa duração – Se o token for válido durante semanas ou meses, dá mais tempo aos atacantes.

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.

Melhores práticas no uso de tokens bearer#

Para usar tokens bearer com segurança, é essencial seguir as melhores práticas. Eis algumas, com exemplos:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

Tokens bearer vs. outros métodos de autenticação#

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.

Resumo#

• Tokens bearer são simples mas poderosos: quem tem o token acede ao recurso.
• São muito usados em OAuth 2.0 e OIDC, sobretudo para APIs e apps móveis.
• A segurança depende do teu manuseamento: duração curta, scopes, HTTPS e revogação são essenciais.
• Não são sempre a melhor escolha, mas para SaaS e APIs costumam ser o equilíbrio certo entre segurança e comodidade.