No GT do cliente estava ocorrendo um problema estranho, assim que o sistema me direcionava para a dashboard da aplicação, ele também fazia o logout automático, impedindo que eu usasse o sistema.
Na lista de requests havia o seguinte:

• GET v1/requestExemplo.....
• GET v1/notificacoes....
• GET v1/requestExemplo2....
• POST v1/logout.....

Note que o logout acontece logo após a primeira request da aplicação depois de ter sido feita a coleta das notificações....

Cenário de configuração do cliente

O cliente roda Ponto, Akita e GT na mesma infra. Ponto e Akita usam insoft-auth e insoft-notification-api conectados na base ponto7, enquanto GT a princípio usa insoft-auth e insoft-notification-api conectados na base gtsoft.

Todavia, após análise foi visto que nos arquivos de configuração do gtsoft (back e front), a url da insoft-notification-api está apontando para o endereço onde está rodando a insoft-notification-api do Ponto e Akita.

Essa configuração faz o token criado na base do GT ser invalidado pelo insoft-auth do insoft-notification-api do Ponto (por conta desse token não estar disponível na base do Ponto).
Assim que o gtsoft-api recebe uma request com um token inválido, ele devolve um header na response indicando ao frontend que é necessário deslogar pois o token é inválido.

Correção

Após colocar nos arquivos de configuração do GT a url do insoft-notification-api que é de fato do GT, o logout deixou de ocorrer. Essa alteração no arquivo exige a reinicialização do gtsoft-api caso for feita alteração no application.yml.

Observação

Em algumas ocasiões onde o cliente usa proxy reverso, pode ser que a config de url do insoft-notification-api precise estar com localhost+porta ao invés do nome do domínio, no caso de estar no mesmo server que a aplicação final. Isso vai depender da configuração do proxy, mas no geral parece estar sendo comum a necessidade de usar localhost ao invés do domínio mascarado.