# Autenticacao com access token e refresh token

Implementar fluxo completo de renovacao automatica de tokens:

- Login deve retornar `access_token` com expiracao curta e `refresh_token` com expiracao maior.
- Criar rota exclusiva `POST /auth/refresh` para renovar o access token usando apenas o refresh token.
- Frontend deve interceptar `401 Unauthorized`, renovar o token, atualizar os tokens armazenados e repetir a requisicao original automaticamente.
- Evitar multiplas chamadas simultaneas de refresh; chamadas concorrentes devem aguardar a primeira renovacao.
- Se refresh token estiver expirado, invalido ou revogado, limpar tokens, encerrar sessao e redirecionar para login.
- Centralizar a logica no cliente HTTP.

## Solicitacao complementar - 16/07/2026

Completar o fluxo de sessao para evitar que a tela fique travada quando o acesso expirar:

- O token de acesso deve durar 1 hora.
- O refresh token deve durar 7 dias.
- A rota de renovacao deve emitir um novo token de acesso valido por mais 1 hora.
- O frontend deve guardar os dois tokens.
- Cinco minutos antes do fim da hora, exibir um dialog perguntando se a pessoa ainda esta usando o sistema.
- Ao confirmar, renovar o token de acesso.
- Sem resposta ate o fim do prazo, limpar a sessao e voltar para o login.
- Ao fechar o sistema sem logout e retornar em outro dia, renovar o acesso com o refresh token e abrir normalmente o sistema.

## Resposta

Fluxo implementado no backend e no frontend:

- O prazo padrao do refresh token foi alterado para 604800 segundos (7 dias), inclusive no arquivo de configuracao de exemplo.
- A renovacao passou a limitar tambem tokens emitidos antes da alteracao a no maximo 7 dias desde a emissao.
- A rota existente `POST /public/auth/refresh` continua emitindo um novo token de acesso por 3600 segundos (1 hora).
- Token de acesso, refresh token e usuario agora persistem pelo prazo correto mesmo depois de fechar o navegador.
- A protecao das rotas valida a expiracao real dos tokens e renova o acesso antes de abrir uma tela protegida quando o sistema e reaberto.
- Foi adicionado um dialog global cinco minutos antes da expiracao, com contagem regressiva, opcao para continuar e encerramento automatico sem resposta.
- A renovacao concorrente continua centralizada em uma unica chamada, e falhas limpam todos os dados locais antes do redirecionamento.
- Validacoes executadas: verificacao de tipos do Vue/TypeScript, sintaxe PHP, imports e resposta local da rota de renovacao.
- O build do frontend aguarda confirmacao, conforme o fluxo definido no projeto.

## Ajuste temporario para teste - 16/07/2026

Solicitado o limite local da sessao em 5 minutos para validar o dialog, a renovacao e o encerramento automatico.

O `JWT_TTL_SECONDS` do arquivo local `back/.env` foi alterado temporariamente de 3600 para 300 segundos. O padrao definitivo no codigo e no arquivo `.env.example` permanece em 1 hora, evitando que a configuracao de teste seja levada por engano para outros ambientes.

Para o dialog nao abrir imediatamente a cada renovacao curta, o aviso passou a usar 20% da duracao da sessao, limitado ao maximo de 5 minutos e ao minimo de 30 segundos. Assim, no teste de 5 minutos ele aparece no ultimo minuto; com a configuracao normal de 1 hora, aparece nos ultimos 5 minutos.

## Encerramento do teste - 16/07/2026

Depois da validacao do fluxo, o `JWT_TTL_SECONDS` local foi restaurado para 3600 segundos (1 hora). O refresh token permanece valido por 7 dias e o dialog volta a aparecer nos ultimos 5 minutos da sessao.
