O que são tokens de portador?
Aprenda o que são tokens de portador, como funcionam no OAuth 2.0 e JWT, a diferença em relação aos tokens de acesso e as melhores práticas.
Por trás de quase todo login de aplicativo moderno ou solicitação de API está um trabalhador silencioso: o token de portador. Você pode não percebê-lo, mas ele está lá toda vez que você conecta serviços, faz login ou busca dados na nuvem.
Este guia explica o que os tokens de portador fazem, por que são importantes e como lidar com eles de forma segura.
O que é um token de portador?
Um token de portador é um pedaço de dado, geralmente uma sequência de caracteres, que prova que quem o possui pode acessar um recurso. O importante é que qualquer pessoa que porta o token pode usá-lo sem precisar fornecer prova extra.
Pense em um cartão de embarque de avião. Quando você está com ele em mãos, pode passar pela segurança e embarcar no avião. Ninguém pede seu documento de novo se o cartão for válido. Da mesma forma, um token de portador permite que seu aplicativo "embarque na API" sem checar sua identidade toda vez.
Por exemplo, após fazer login no Spotify no seu celular, você não precisa digitar sua senha toda vez que for ouvir uma música. Em vez disso, o aplicativo armazena um token de portador que informa aos servidores do Spotify: "esta solicitação vem de um usuário autorizado".
Como os tokens de portador funcionam na prática
O fluxo dos tokens de portador pode ser dividido em alguns passos:
-
Usuário faz login
Suponha que você faz login em um app bancário com seu nome de usuário e senha.
-
Provedor de identidade emite um token
Uma vez verificado, o servidor de autenticação retorna um token de portador. Pode ser algo assim:
-
Cliente usa o token
Sempre que você tocar em "Ver Saldo" ou "Transferir Dinheiro", o app inclui o token na solicitação HTTP:
-
API valida o token
O servidor checa se o token ainda é válido, não expirou e se possui as permissões corretas (como
read:balance
ouwrite:transfer
). -
Acesso concedido
Se todas as verificações passarem, o servidor responde com as informações solicitadas.
Esse modelo é amplamente utilizado em serviços como APIs do GitHub, onde desenvolvedores se autenticam com um token de portador em vez de enviar credenciais repetidamente.
Por que os tokens de portador se tornaram populares
Os tokens de portador se tornaram populares porque resolveram problemas comuns de segurança na web. Diferente de sessões baseadas em servidor, não é necessário armazenar dados para cada usuário logado. O próprio token contém as informações necessárias para o servidor validar as requisições.
Por exemplo, em uma arquitetura de microsserviços, onde dezenas de serviços se comunicam, manter um armazenamento central de sessões seria complexo e ineficiente. Com tokens de portador, cada serviço pode validar requisições de forma independente, deixando o sistema mais leve e escalável.
Um exemplo concreto: as APIs do Slack dependem muito de tokens de portador. Quando você cria um bot do Slack, recebe um token que permite seu bot chamar os endpoints do Slack sem manter sessão para cada usuário.
O que há dentro de um token de portador?
Muitos tokens de portador são implementados como JWTs (JSON Web Tokens). Esses tokens são sequências codificadas que incluem informações sobre o usuário e suas permissões.
Vamos decodificar um JWT de exemplo:
O que isso significa:
sub
: O sujeito, ou ID único do usuário.name
: O nome do usuário.iat
: Timestamp de emissão.exp
: Tempo de expiração (quando o token se torna inválido).scope
: As permissões, neste caso permitindo ao app ler e escrever mensagens.
Na prática, se o token de Jane tivesse apenas o escopo read:messages
, o app poderia apenas buscar as mensagens dela, mas não enviar uma nova em seu nome.
Tokens de portador vs. tokens de acesso: Qual a diferença?
É fácil confundir tokens de portador com tokens de acesso, pois os dois termos frequentemente aparecem juntos. Na verdade, eles são relacionados, mas não idênticos.
Token de acesso: O “bilhete de permissão”
Um token de acesso é uma credencial que representa a autorização de um usuário para acessar um recurso. Ele carrega informações como:
- Quem é o usuário (seu ID)
- O que ele pode fazer (escopos/permissões)
- Quando expira o token
Pense em um bilhete de permissão assinado pelo diretor da escola. Ele mostra à professora (a API) que você pode ir ao passeio (acessar o recurso).
Por exemplo, ao fazer login em um serviço de armazenamento em nuvem, o sistema emite um token de acesso com o escopo read:files
. Esse token informa à API de armazenamento: “Esse usuário pode ler arquivos, mas não apagá-los”.
Token de portador: O “formato de entrega”
Um token de portador é um tipo de token de acesso. O termo portador descreve como o token é usado: quem o apresenta pode usá-lo para acessar recursos, sem outra prova de identidade.
Ou seja:
- Todo token de portador é um token de acesso.
- Mas nem todo token de acesso precisa ser um token de portador.
Existem outros tipos de token, como holder-of-key tokens, que exigem que o cliente prove a posse de uma chave criptográfica além do token. Tokens de portador pulam esse passo extra, tornando-os mais simples, mas também mais arriscados em caso de roubo.
Exemplo na prática
- Token de acesso (genérico): Pode ser um dado assinado, às vezes exigindo que o cliente prove também possuir uma chave privada.
- Token de portador (específico): A maioria das implementações do OAuth 2.0 hoje emite tokens de acesso no formato de portador. Por exemplo, o OAuth do Google retorna um token de acesso que você utiliza no cabeçalho Authorization: Bearer
<token>
.
Portanto, quando você vê “token de acesso” em tutoriais de OAuth, quase sempre é um token de portador, a menos que seja especificado o contrário.
Outros tipos de token comparados
Para deixar o quadro mais claro, vejamos como os tokens de portador se comparam com outros tipos comuns:
- Token de refresh: Usado para obter um novo token de acesso quando o antigo expira. Tokens de refresh geralmente não são de portador, pois são trocados de forma segura com o servidor de autorização e não enviados diretamente para APIs.
- ID token: Usado para autenticação, não autorização. Carrega informações de identidade do usuário (como e-mail, nome ou ID). Dependendo do sistema, um ID token também pode ser de portador, mas seu propósito é diferente de um token de acesso.
- API key: Uma forma mais simples de credencial que identifica o aplicativo que está chamando a API. Em muitos casos, chaves de API agem como tokens de portador, já que quem tem a chave pode chamar a API.
Tokens de portador e tokens de acesso não são conceitos opostos — eles estão relacionados:
- A maioria dos tokens de acesso são tokens de portador.
- Um token de portador descreve como um token é usado (apresente-o para obter acesso).
- No uso cotidiano, os termos “token de acesso” e “token de portador” costumam ser usados como sinônimos, mas tecnicamente destacam aspectos diferentes.
Como validar um token de acesso JWT (token de portador)
Validar um token de portador é o que protege sua API de acessos não autorizados. Se seus tokens são JWTs, a validação acontece localmente e rapidamente. A API pode checar o token sem consultar o emissor a cada vez.
A ideia central
- Analise o token.
- Verifique a assinatura usando a chave pública do emissor.
- Verifique as claims padrão como emissor, audiência, expiração, not-before.
- Aplique as regras do seu app como escopos, funções e tipo do token.
- Opcionalmente consulte listas de revogação ou estado de sessão para ações de alto risco.
Checklist de validação (JWT)
Use isto como um guia ao configurar um API gateway ou middleware.
-
Assinatura
Verifique a assinatura usando o algoritmo no header (por exemplo RS256). Busque o endpoint JWKS do emissor, escolha a chave que corresponde ao kid e faça cache dela.
-
Emissor (iss)
Compare o iss do token com a URL do seu emissor confiável, exatamente igual e com o esquema correto.
-
Audiência (aud)
Certifique-se de que o token foi destinado para sua API. Compare com o identificador da sua API como https://api.example.com ou um string lógico de audiência.
-
Expiração (exp) e Not-Before (nbf)
Rejeite tokens expirados. Respeite o nbf para que o token não possa ser usado antes do tempo de início. Permita um pequeno desvio de relógio, normalmente de 30 a 60 segundos.
-
Emitido em (iat)
Útil para depuração e para rejeitar tokens muito antigos em configurações estritas.
-
Tipo de token
Confirme que é um token de acesso. Alguns provedores incluem typ: "at+jwt" ou similar. Não aceite ID tokens para acesso de API.
-
Escopos / permissões
Leia o escopo ou claims específicas do provedor (por exemplo permissões, funções). Aplique o menor privilégio possível em cada endpoint.
-
Assunto (sub)
O ID estável do usuário ou cliente. Use para associar recursos e para auditoria.
-
Replay e revogação (opcional, mas recomendável)
Para endpoints sensíveis, cheque uma lista de negação de curta duração de valores jti, ou valide um registro de sessão ativa. Isso ajuda após logout ou suspeita de comprometimento.
Riscos de segurança dos tokens de portador
Como tokens de portador são “quem possui pode usar”, devem ser tratados como chaves de casa. Se alguém rouba a sua chave, pode abrir sua porta até você trocar a fechadura.
Alguns riscos comuns:
- Roubo de token – Se um hacker conseguir acessar o localStorage do navegador onde o token está salvo, ele pode se passar pelo usuário. Por exemplo, em 2018, algumas extensões de navegador foram flagradas roubando tokens do localStorage e vendendo-os.
- Ataques de replay – Um invasor que interceptar um token pode reutilizá-lo até que expire. Sem HTTPS, isso é surpreendentemente fácil.
- Tokens de longa duração – Se um token for válido por semanas ou meses, amplia a janela de oportunidade dos atacantes.
Já ocorreram vazamentos reais quando desenvolvedores acidentalmente submeteram tokens de portador a repositórios públicos no GitHub. Atacantes podem escanear por esses tokens e explorá-los imediatamente para obter acesso não autorizado.
Melhores práticas para usar tokens de portador
Para usar tokens de portador com segurança, é importante seguir as boas práticas. Vamos abordá-las com exemplos:
-
Sempre use HTTPS
Imagine enviar um token por HTTP simples numa rede Wi-Fi pública de café. Qualquer um monitorando a rede poderia copiar o token e fazer login como você.
-
Use tokens de acesso de curta duração
A maioria das plataformas emite tokens que expiram em uma hora. Por exemplo, os tokens OAuth do Google normalmente duram uma hora antes de exigir refresh.
-
Utilize tokens de refresh com cuidado
Um token de refresh pode solicitar novos tokens de acesso sem exigir novo login do usuário. Mas deve ser armazenado com segurança (por exemplo, em um banco de dados criptografado no servidor), não em armazenamento do lado do cliente.
-
Restrinja os escopos ao mínimo necessário
Se seu app só precisa ler um calendário de usuário, não peça write:calendar. Isso minimiza danos em caso de comprometimento do token.
-
Revogue tokens quando necessário
Muitos apps SaaS permitem aos usuários visualizar sessões ativas e revogá-las. O GitHub, por exemplo, permite revogar tokens de acesso pessoal a qualquer momento.
-
Monitore o uso
Fazer logging do uso de tokens pode revelar atividades suspeitas. Se o mesmo token for usado subitamente em Londres e Nova York em poucos minutos, isso é um alerta.
Tokens de portador vs. outros métodos de autenticação
É útil comparar tokens de portador com outras abordagens populares:
-
Cookies & Sessões
Sites tradicionais usam sessões armazenadas no servidor identificadas por um cookie. Isso funciona bem para apps de navegador, mas é menos eficiente para APIs ou apps móveis. Por exemplo, fazer login no Facebook no desktop usa primariamente cookies, enquanto suas APIs móveis usam tokens.
-
Chaves de API
Uma chave de API é uma string estática que autentica o aplicativo, não o usuário. Por exemplo, um app de previsão do tempo pode usar uma chave de API para buscar dados, mas a chave não informa ao servidor qual usuário pediu a previsão. Tokens de portador podem carregar dados específicos do usuário, tornando-os mais versáteis.
-
TLS mútua (mTLS)
Alguns sistemas de alta segurança usam certificados no cliente e no servidor. Embora mais seguro, esse modelo é mais difícil de escalar. Para a maioria das plataformas SaaS, tokens de portador oferecem o equilíbrio certo entre usabilidade e segurança.
Principais pontos
- Tokens de portador são simples, mas poderosos: quem detém o token pode acessar o recurso.
- São amplamente usados nos fluxos do OAuth 2.0 e OIDC, especialmente para APIs e apps móveis.
- A segurança depende de como você os gerencia: tempos de vida curtos, escopos, HTTPS e revogação são importantes.
- Não são sempre a melhor escolha, mas na maioria dos cenários SaaS e APIs, oferecem o equilíbrio certo entre segurança e conveniência.