0002 — Bearer estático para /api/**¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-16 · Decidido em: 2026-04-01
Correção 2026-07-16: o endpoint de ingestão citado no Contexto mudou de nome e de formato — hoje é
POST /api/xls/processar, que recebe um.zipcom os.xlsxdo lote. É um fato incidental do contexto, não da decisão: o Bearer estático para/api/**segue valendo, e a nova rota está sob a mesma proteção (@Secured("ROLE_API")). Estado atual do contrato no livro.
Contexto¶
O endpoint de ingestão (POST /api/xls/processar) é consumido por um
cliente server-to-server único e confiável — a automação que envia as
planilhas comerciais. Não há usuário final humano nem múltiplos consumidores no
/api/**; a superfície é máquina-para-máquina.
Decisão¶
Proteger /api/** com Bearer token estático via micronaut-security
(@Secured("ROLE_API")). O token é injetado por env e comparado; não há emissão,
rotação automática nem claims. As views server-rendered têm um esquema
próprio e independente (login Google — ver 0003).
Consequências¶
- Integração simples: o cliente manda
Authorization: Bearer <token>e pronto. - Sem infraestrutura de emissão/refresh de JWT para um único consumidor confiável.
- Rotação é operacional (trocar a env e redeployar) — aceitável para o volume de consumidores (um).
- Não mexer neste esquema ao trabalhar em auth das views: são camadas independentes.
Alternativas consideradas¶
- JWT assinado com claims/expiração: dá rotação e escopo por claim, mas é excesso para um único cliente confiável server-to-server. Descartado por over-engineering.
- mTLS: mais forte, porém mais custo operacional de certificados para um ganho marginal neste cenário. Descartado.