Como garantir a validade do JWT ao usar next auth com OAuth 2.0 personalizado

Quando implementamos OAuth 2.0 próprio e integramos com next-auth, um dos maiores desafios é manter o token JWT acessível no cliente. No meu time, já passei por isso e o que funciona bem é configurar o callback de sessão para passar o token de acesso ao lado do cliente, além de garantir que o provider personalizado esteja retornando o token completo.

A dica é verificar se o seu callback de JWT está configurado corretamente, salvando o token durante o login e repassando na sessão. Assim, evita o problema do token nulo na UI.

Outro ponto importante é o refresh do token, que pode gerar inconsistências se não tratado. Recomendado fazer uma rotina de refresh automática, especialmente se seu OAuth é customizado e não segue o padrão padrão do next-auth.

No meu entendimento, o maior pulo do gato é garantir que o token não fique só na resposta do login, mas seja mantido na sessão de forma confiável para o client-side. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.

Como vocês têm lidado com a segurança e validação do token nesse cenário? Alguma estratégia que tenha ajud ado a evitar problemas de expiração ou invalidação inesperada? Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.