Pular para o conteúdo

apps/security/token-auth

147 · Segurança & Auditoria · ≈ 6 min de estudo

Token Auth

Autentica cada requisição com um JWT assinado (HMAC-SHA256), verificado em qualquer instância sem consultar banco. Dois tokens: access de 15 minutos no header Authorization, refresh de 7 dias num cookie HttpOnly. O refresh é rotacionado a cada uso, e a revogação — por token (jti) ou por usuário (versão) — fica no Redis, com TTL igual à vida restante do token.

passos
6
arquivos
5
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaRedisDocker
Baixar cartão

Cenário

Maria entra no app do banco e consulta o saldo. O app renova a sessão com o refresh token, que é rotacionado. Um atacante que roubou o refresh antigo tenta usá-lo: o reuso é detectado e todas as sessões de Maria caem, inclusive a do atacante. No logout, o access e o refresh são revogados na hora. Um token com roles editado para admin falha na assinatura.

Planta

Sequência
9/9
POST /auth/login1access (body) + refresh (cookie HttpOnly)2GET /accounts/balance (Bearer access)3assinatura em tempo constante, type, exp4jti revogado? versão do usuário?52006POST /auth/refresh (cookie)7SET bl:jti NX EX restante8par novo9NX falhou: refresh reutilizado,INCR tv:usuário derruba todas as sessõesApp do clienteAPIRedis
9

9 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Token assinado prova a identidade.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    tokenSign monta header.payload em base64url e assina com HMAC-SHA256; os claims levam type, jti, ver, iat e exp — e nada sensível, porque não são cifrados

  2. 02

    tokenVerifySigned confere o header exato (barra alg: none), a assinatura com timingSafeEqual após checar o tamanho, o type e o exp

  3. 03

    tokenIsLive consulta o Redis: jti na blacklist ou ver diferente da versão atual do usuário recusam o token

  4. 04

    /auth/refresh revoga o refresh com SET NX; se ele já estava revogado, é reuso — INCR na versão derruba todas as sessões

  5. 05

    /auth/logout revoga access e refresh com TTL = tempo restante; /auth/logout-all só incrementa a versão

  6. 06

    O guard (resolve) vale para as rotas registradas depois dele: login e refresh ficam abertos

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Assinatura verificada localmente, sem banco por requisição

  • Access curto limita o dano de um token interceptado

  • Versão por usuário encerra todas as sessões com um INCR

  • Payload legível facilita depuração

Custos

  • Revogação imediata exige uma ida ao Redis por requisição

  • Refresh longo precisa de rotação e detecção de reuso

  • Encerrar todas as sessões também derruba o dono legítimo

  • Nada sensível pode ir nos claims; o segredo HMAC vazado permite forjar qualquer token

apps/security/token-auth

5 arquivos

src/

  • token_jwt.tsAssinatura e verificação HS256 em tempo constante, tipo e expiração
  • token_store.tsUsuários, blacklist de jti com TTL e versão por usuário no Redis
  • api_auth.tsLogin, refresh com rotação e detecção de reuso, logout, logout-all e rota protegida
  • config_token.tsConfiguração validada do ambiente
  • demo.tsdemoSessão, rotação, replay do refresh, logout e token adulterado

Executar · com Docker

  1. ./docker.sh up# sobe Redis
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
Redis

Por que se relacionam

Teste rápido

Qual é o próximo passo depois de Token-Based Authentication?

Próximo projeto · Segurança & AuditoriaAPI Key Management
Esc

↑ ↓ navegarEnter abrir191 resultados