Alinhar a validade do login entre serviços: renovação e reautenticação

Usar uma conta comum não torna idênticas as sessões das aplicações e do provedor de identidade. O caso alinha regras sem publicar destinos ou prazos.

Comparar a mesma solicitação antes e depois da expiração

Use um prazo curto em testes. Execute separadamente login explícito, navegação e atualização em segundo plano, comparando a expiração no servidor. Depois, teste a mesma operação na interface e API, verificando reautenticação e recusa de acesso. Registre esse teste separado da operação prolongada em produção.

OWASP：Projeto e testes da expiração de sessão

Identificar cada prazo

Inventarie separadamente a sessão do provedor, a sessão da aplicação e o cookie. Expiração absoluta, inatividade e rotação do identificador são controles diferentes. Trocar o identificador não exige estender a validade.

Separar login explícito e acesso comum

O caso renova o período aplicável após um login explícito bem-sucedido, não por navegação, tráfego de fundo, renovação automática de tokens ou rotação do identificador; esses mantêm o prazo original. Um clique ou chegada ao callback não comprova autenticação: valide o resultado. Quando autenticação recente for necessária, verifique se reutilizar a sessão do provedor atende ao requisito.

Aplicar a validade no servidor

Um cookie mais duradouro não define o período aceito pelo servidor. Confira prazo, revogação, cookie e limites do provedor. Regras iguais não implicam cookie compartilhado ou logout imediato em todos os serviços.

Valide o horário de autenticação e expiração da autoridade e limite a eles as sessões das aplicações. O contrato comum valida sessões; permissões de negócio continuam em cada aplicação. Um gateway com cookie próprio tem outro limite a inventariar e auditar.

1. 1 Provedor de identidade e callback Valide o resultado da autenticação e o context/state do callback. O login, por si só, não concede acesso ao aplicativo.
2. 2 Aplicativo, cookie e gateway Verifique separadamente a expiração e a revogação da sessão no servidor, do cookie do navegador e da sessão do gateway.
3. 3 Permissões de cada serviço Cada aplicativo verifica as próprias permissões. O tráfego normal e a atualização em segundo plano não estendem o prazo nem implicam logout global.

Separar configuração e comportamento

Audite código e ajustes separadamente dos testes de login, limites de validade, login após expiração e logout. Confira quando a nova regra se aplica a sessões existentes e como páginas e APIs tratam a expiração. Registre decisões e horários, sem valores de sessão ou credenciais.

Escopo confirmado

O histórico registra mudanças, publicação e ferramentas para auditar diferenças. Os registros não incluem login de usuários reais nem espera até a expiração efetiva. Não demonstra testes de tempo real em todos os dispositivos nem toda a segurança da revogação e reautenticação. Escolha prazos e verificações conforme dados e operações.

Consulte sessões OWASP e autenticação. Para outra camada, veja sessões Cloudflare. As recomendações não significam que cada teste foi concluído neste caso.

Atualização de 6 de outubro de 2026: continuidade da autenticação e permissões do aplicativo

No registro anonimizado de uma alteração de autenticação, foram separados a chegada ao callback OIDC, a validação do token, a continuidade da solicitação de autenticação original e as permissões para usar o aplicativo. Se faltar o contexto necessário para continuar, o fluxo não apresenta isso como um login bem-sucedido: retorna um erro seguro que permite retomar o processo. O destino de retorno também é validado; entrar em uma conta compartilhada não concede, por si só, permissões de negócio em cada aplicativo.

O mesmo contrato é verificado no login e no cadastro, ao adicionar ou remover provedores de autenticação e nos caminhos de recuperação. Os registros de alterações e deploy não comprovam que todas as pessoas conseguem entrar com todos os provedores nem que a preservação do último método de recuperação foi testada de ponta a ponta.

A ativação de um segundo fator, o login na plataforma de identidade, a passagem pelo controle de acesso e uma gravação protegida no aplicativo também são verificados separadamente. Um teste limitado de gravação não substitui a verificação de todos os fluxos formais de OIDC nem comprova a rejeição de uma conta desativada. O cadastro, a configuração inicial, as telas de alteração e a API consultam as mesmas regras de entrada; os testes verificam juntos os valores de limite que devem ser rejeitados ou aceitos. Nenhum comprimento específico é apresentado como padrão universal.

As telas e instruções de callback para login e cadastro também são separadas. Exibir uma tela ou confirmar o estado de saúde não equivale à aceitação da criação real de uma conta externa ou da concessão de consentimento. Ao remover um provedor, são revisados em conjunto o botão, o callback, a configuração, as instruções e os testes, e depois se verifica se restou algum caminho.