0037 — Sessão dos apps: access curto, refresh e teto¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-15 · Decidido em: 2026-09-15
Complementa a 0029, em que o papel vem do grant, e a 0030, em que um projeto de identidade serve N apps.
Contexto¶
O central-backend emite o JWT de sessão dos apps com usuário (pAbast e social) e relê status e papel
só no login. Todo consumidor valida o token pelo JWKS até o exp, o PowerSync inclusive, sem consultar
revogação. Com o token valendo 24h, o usuário inativado segue com acesso e a troca de papel não chega ao
app até o exp ou um novo login. E a sessão pAbast não re-loga sozinha depois de recarregar a página: a
senha vive só em memória, e a norma proíbe persisti-la.
Decisão¶
- O prazo de revogação é o TTL do access token, e o TTL é curto: no máximo 60 min. O valor é config
do
central-backend, o único emissor, e vale para todo consumidor de uma vez. App que não renova não fica inseguro: re-loga. - O app renova sem a senha, trocando o token vigente por um novo no endpoint de refresh do central,
que repete as checagens do login (cliente ativo, método de auth permitido, acesso do usuário) e devolve
o papel atual. Revogado, o refresh responde 403 com um código que o app trata como logout. O contrato
(rota, códigos, claims) é do
central-backend. - A sessão tem teto absoluto de no máximo 7 dias, contado do login e preservado a cada refresh. Sem ele a sessão deslizaria para sempre sem re-provar a credencial, e a senha trocada no ERP não derrubaria ninguém.
Alternativas descartadas¶
- Refresh com o TTL de 24h. Conserta a troca de papel no app honesto e deixa a revogação onde estava:
o token segue válido no PowerSync e em toda API até o
exp. - Refresh token opaco, rotativo, guardado no central. Revoga no próximo uso e deixa a sessão ociosa sobreviver até o teto, ao custo de tabela, rotação e detecção de reuso; e o refresh token no browser é tão exfiltrável quanto o access. Fica como evolução se o re-login do ocioso pesar.
- Lista de revogação consultada pelos consumidores. O PowerSync e cada app consultariam o central a cada request, desfazendo a validação local pelo JWKS.
Consequências¶
- Ocioso por mais que o TTL, o token expira e o app pede login de novo.
- A ordem da adoção importa: o refresh no central, depois nos apps que renovam sessão, e só então o TTL cai. Antes disso, cada app sem refresh re-logaria a cada TTL.
- O piso do app está em Segurança.