Skip to main content

RFC Bearer Token (RFC 6750) | API | CSharp

  • RFC Bearer Token (RFC 6750) | API | CSharp

Visão Geral​

A RFC 6750, definida pela IETF, especifica o uso de Bearer Tokens para autenticação em requisições HTTP, principalmente no contexto do OAuth 2.0.

O conceito central é:

  • Um Bearer Token é um token de acesso que concede autorização a quem o possui
  • Não exige prova de posse (como chave privada ou assinatura adicional)
  • Quem "carrega" (bearer) o token tem acesso

Definição de Bearer Token​

Um Bearer Token é:

  • Um access token emitido por um Authorization Server
  • Utilizado para acessar recursos protegidos
  • Transportado em requisições HTTP

Formato padrão:

Authorization: Bearer <token>

A palavra "Bearer" é obrigatória?​

Não — a palavra "Bearer" não é obrigatória tecnicamente, mas é obrigatória quando você decide seguir o padrão da RFC 6750 / OAuth2.

Interpretação correta​

  • "Bearer" é um authentication scheme do header Authorization
  • Ele indica ao servidor como interpretar o token
  • Sem ele, o servidor não sabe qual estratégia aplicar

Quando é obrigatório​

  • Ao usar OAuth 2.0
  • Ao seguir a RFC 6750
  • Ao integrar com gateways e provedores padrão

Exemplo válido:

Authorization: Bearer abc123

Quando não é obrigatório​

Se você controla toda a stack (cliente + servidor), pode usar outros formatos:

Sem scheme​

Authorization: abc123

Scheme customizado​

Authorization: Token abc123

Header customizado​

X-Auth-Token: abc123

Impacto de não usar "Bearer"​

  • Quebra compatibilidade com ferramentas padrão
  • Gateways não reconhecem automaticamente
  • Exige implementação manual de parsing
  • Reduz interoperabilidade com terceiros

Forma de Envio do Token​

A RFC define três formas principais:

Header Authorization (RECOMENDADO)​

GET /resource HTTP/1.1
Host: api.exemplo.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Query Parameter (NÃO RECOMENDADO)​

GET /resource?access_token=abc123

Form-Encoded Body​

POST /resource
Content-Type: application/x-www-form-urlencoded

access_token=abc123

Respostas de Erro​

Token ausente ou inválido​

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

Token inválido​

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token"

Permissão insuficiente​

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope"

Campos do WWW-Authenticate​

  • realm
  • error
  • error_description
  • error_uri

Exemplo:

WWW-Authenticate: Bearer realm="api",
 error="invalid_token",
 error_description="The access token expired"

Segurança​

Principais riscos​

  • Interceptação (MITM)
  • Vazamento em logs
  • Replay attack

Boas práticas​

  • Usar HTTPS obrigatoriamente
  • Não enviar token em query string
  • Expiração curta
  • Uso de refresh token
  • Validação de escopo

Relação com JWT​

Bearer Tokens frequentemente utilizam JWT.

Exemplo:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Importante:

  • A RFC não exige JWT
  • O token pode ser opaco ou estruturado

Fluxo Simplificado​

  1. Cliente autentica no Authorization Server
  2. Recebe access_token
  3. Envia token na requisição
  4. Resource Server valida
  5. Retorna resposta

Exemplo com curl​

curl http://api.exemplo.com/resource \
  -H "Authorization: Bearer abc123"

Uso com API Gateway​

Gateways como:

  • Apache APISIX
  • Kong

Podem:

  • Validar presença do token
  • Verificar expiração
  • Validar assinatura
  • Aplicar políticas de acesso

Casos de Uso​

  • APIs REST protegidas
  • Microservices
  • Integrações externas
  • Aplicações web/mobile

Observações Técnicas​

  • Bearer não prova posse (apenas portador)
  • Não possui revogação nativa
  • Depende de transporte seguro
  • Deve ser combinado com OAuth2/OpenID Connect