diff --git a/apps/api/src/auth/token.service.ts b/apps/api/src/auth/token.service.ts index 48f1b0d..d444909 100644 --- a/apps/api/src/auth/token.service.ts +++ b/apps/api/src/auth/token.service.ts @@ -9,7 +9,16 @@ export interface AccessTokenPayload { app: "core" | "reseller" | "subscriber"; } -const ACCESS_TOKEN_TTL_SECONDS = 15 * 60; // 15 min — ADR-0003 +/** + * 8h — revisado a partir dos 15min originais da ADR-0003 (ver o adendo no + * próprio documento): o frontend não implementa refresh silencioso ainda + * (`AuthContext.tsx`, `session.ts` — "No refresh-token rotation in this + * leva"), então um access token de 15min derrubava o usuário no meio do + * trabalho. 8h cobre um expediente inteiro sem exigir login de novo; + * revogação continua granular via a tabela `sessions` (logout/"encerrar + * todas as sessões" não dependem da expiração do JWT). + */ +const ACCESS_TOKEN_TTL_SECONDS = 8 * 60 * 60; const REFRESH_TOKEN_TTL_DAYS = 30; const MFA_CHALLENGE_TTL_SECONDS = 2 * 60; const MFA_CHALLENGE_PURPOSE = "mfa_challenge" as const; diff --git a/docs/adr/0003-auth-sessions.md b/docs/adr/0003-auth-sessions.md index 8adbe19..15deeda 100644 --- a/docs/adr/0003-auth-sessions.md +++ b/docs/adr/0003-auth-sessions.md @@ -7,7 +7,7 @@ Aceito O legado usa JWT HS256 com payload mínimo (`sub`, `ver`), expiração fixa de 30 dias, sem refresh token, invalidação via `token_version` incremental (derruba todas as sessões de uma vez, nunca uma só). O Master Prompt (§5.3) pede explicitamente uma evolução: access token curto + refresh token rotativo (ou sessão server-side segura), refresh tokens armazenados em hash, histórico de sessões/dispositivos, "encerrar todas as sessões", MFA/TOTP preparado. ## Decisão -- **Access token**: JWT de vida curta (15 min), payload mínimo (`sub`, sessão id), assinado (algoritmo a confirmar em ADR de criptografia geral — HS256 mantém paridade com o legado, RS256 fica em aberto se houver necessidade de verificação por serviço externo). +- **Access token**: JWT de vida curta, payload mínimo (`sub`, sessão id), assinado (algoritmo a confirmar em ADR de criptografia geral — HS256 mantém paridade com o legado, RS256 fica em aberto se houver necessidade de verificação por serviço externo). TTL original 15min, revisado para 8h — ver adendo 2026-09-18. - **Refresh token**: opaco, alta entropia (≥256 bits), **rotativo a cada uso** (um novo é emitido e o antigo invalidado), armazenado só como hash no banco (nunca em claro) — mesma filosofia do token de link público do legado. - **Tabela `sessions`** (não só um contador `token_version`): permite listar sessões/dispositivos ativos e revogar individualmente **ou** todas de uma vez (superset da capacidade do legado, que só permitia "todas"). - **Vínculo por aplicação**: uma sessão registra explicitamente para qual aplicação (`core`/`reseller`/`subscriber`) foi emitida — nunca inferir pelo papel do usuário (Master Prompt §5.1). @@ -19,3 +19,9 @@ O legado usa JWT HS256 com payload mínimo (`sub`, `ver`), expiração fixa de 3 - Positivo: access token de vida curta reduz janela de uso de token vazado sem exigir consulta ao banco a cada request (mesma vantagem de performance que o legado tinha com JWT, mas com menor exposição). - Negativo: mais complexidade que o modelo legado (rotação de refresh token exige lógica de "replay detection" — se um refresh token já usado for reapresentado, é sinal de token roubado; a sessão inteira deve ser revogada nesse caso). - Migração: nenhuma — é um sistema novo, não há sessões legadas para migrar. + +## Adendo — 2026-09-18: TTL do access token revisado de 15min para 8h + +O frontend nunca implementou refresh silencioso (`apps/core-web/src/lib/auth/AuthContext.tsx`/`session.ts` documentam isso explicitamente: "No refresh-token rotation in this leva"). Na prática, 15min derrubava o usuário no meio de um cadastro/edição em uso normal do backoffice — usuário pediu explicitamente pelo menos 8h. `ACCESS_TOKEN_TTL_SECONDS` em `apps/api/src/auth/token.service.ts` ajustado para `8 * 60 * 60`. + +Isso é uma troca deliberada de exposição por conveniência — o risco que a decisão original mitigava (janela de uso de um token vazado) fica maior. Mitigado por: a arquitetura de `sessions` já permite revogar uma sessão específica ou todas a qualquer momento (login com nova senha após reset já revoga tudo — `password-reset.spec.ts`), então um access token vazado ainda pode ser cortado sem esperar o TTL expirar, só não automaticamente. **Trabalho futuro real, não feito agora**: implementar refresh silencioso no frontend (ex. renovar o access token em background antes de expirar, ou reagir a um 401 chamando `/auth/refresh` e repetindo a requisição) permitiria voltar a um TTL curto sem prejudicar a UX — o TTL de 8h é um paliativo, não a solução definitiva. diff --git a/docs/progress.md b/docs/progress.md index 264144d..b18ed7b 100644 --- a/docs/progress.md +++ b/docs/progress.md @@ -731,3 +731,34 @@ Data: 2026-09-18. Usuário pediu: "primeiro vem os dados PJ depois vem os sócio ### Verificação `pnpm turbo run typecheck build` 28/28. Suíte 100/100 (inalterada — mudança é só de frontend). Testado ao vivo em navegador real via Playwright: ordem das seções confirmada por leitura do DOM (`Status, Dados PJ, Sócios, Endereço, Contatos`) e por screenshot; ciclo completo com CNPJ real (Petrobras) mostrando os 10 sócios na nova posição; salvamento testado preenchendo um campo de cada `
` e confirmando após reload que os dois persistiram. Cadastro de teste desativado ao final. + +--- + +## Access token: 15min → 8h + +Data: 2026-09-18. Usuário pediu diretamente: "ajuste o tempo de acesso do token preciso que seja no mínimo 8 horas". Implementado diretamente (mudança pequena, uma constante). + +`ACCESS_TOKEN_TTL_SECONDS` em `apps/api/src/auth/token.service.ts`: `15 * 60` → `8 * 60 * 60`. Achado ao investigar antes de mudar: o TTL curto original era uma decisão deliberada e documentada (ADR-0003, motivada pelo Master Prompt §5.3 — reduzir a janela de uso de um token vazado), mas o frontend nunca implementou refresh silencioso (`AuthContext.tsx`/`session.ts` documentam isso explicitamente: "No refresh-token rotation in this leva") — na prática, 15min derrubava o usuário no meio do trabalho, sem nenhum mecanismo automático de renovação. 8h é um paliativo real pro problema real, não só "afrouxar por afrouxar": documentado como tal num adendo na própria ADR-0003, com a mitigação que já existe (revogação de sessão continua granular, não depende do TTL do JWT) e o trabalho futuro real que resolveria isso sem abrir mão de segurança (refresh silencioso no frontend). + +### Verificação +`pnpm turbo run typecheck build` 28/28. Suíte completa 106/106 (após a leva de Revenda abaixo, rodada em conjunto). Testado ao vivo: login real devolve `expiresIn: 28800` (exatamente 8h). + +--- + +## Cadastro de Revenda — mesma expansão do Cadastro de Cliente (CNPJ, campos, reordenação) + +Data: 2026-09-18. Usuário pediu pra aplicar em Revenda a mesma coisa feita em Cliente: "fazer a busca automática de cnpj e expandir campos de cadastro e reordenar os campos". A tabela `resellers` até agora era minimalista (`name`/`document`/`contact_email`/`active`, sem endereço, sem sócios, sem os campos PJ que `client_registrations` já tinha). + +### Backend (agente `eden-commercial`) + +Migration `packages/database/migrations/1789700000000_resellers-expansion.cjs`: `resellers` ganha `trade_name`, `state_registration`, `municipal_registration`, `opening_date`, `legal_nature`, `cnpj_situation`, `main_activity`, `address_*`, `contact_principal/financial/technical_*` — mesmo shape de `client_registrations`, sem o prefixo `pj_` (não existe ambiguidade PF/PJ aqui — decisão deliberada: revenda não ganhou um `person_type`, é sempre tratada como PJ). Tabela nova `reseller_partners`, mesmo shape de `client_registration_partners`. + +Endpoints novos em `resellers.controller.ts`: `GET/POST /v1/resellers/:id/partners`, `PATCH /v1/resellers/:id/partners/:partnerId`, e `POST /v1/resellers/:id/cnpj-lookup` — **reaproveitando o adapter `lookupCnpj` já existente** (`@eden/integrations`, construído pra Cliente), mesma mecânica exata (servidor sempre reconsulta a fonte autoritativa, `COALESCE` em tudo que a API pode não trazer, dedup de sócios por `document`, `source: 'cnpj_lookup'`). + +**Decisão deliberada, diferente de Cliente**: `document` continua livremente editável via `PATCH` genérico — ao contrário de `pj_cnpj` em `client_registrations` (que é bloqueado de propósito, só a ação dedicada de lookup grava). Aqui a busca de CNPJ é só uma conveniência adicional, não uma trava nova. + +### Verificação +`pnpm db:migrate`/`down`/`migrate` de novo — limpo. `pnpm turbo run typecheck build` 28/28. Suíte 106/106 (100→106, 6 testes novos). Testado ao vivo contra CNPJ real (Petrobras): nome/nome fantasia/inscrição estadual/endereço/10 sócios corretos, reexecução sem duplicar, `PATCH` manual em `document` confirmado ainda funcionando depois do lookup. + +### Pendências +UI ainda não construída — só o backend nesta leva (frontend é o próximo passo natural, mesmo padrão de Cliente: Dados PJ → Sócios → Endereço → Contatos, já direto na ordem certa desta vez, sem precisar de uma segunda leva de reordenação).