Todos nós adoramos como apps nativos pedem para você fazer login apenas uma vez e depois se lembram de você até dizer que quer sair. Infelizmente, a Web nem sempre funciona assim.
Agora que os dispositivos, especialmente os móveis, são mais pessoais e como mais sites enviam todo o tráfego por HTTPS reduzindo o risco de roubo de tokens, os sites precisam reconsiderar as políticas de cookies de curta duração e adotar sessões mais longas e mais fáceis de usar.
No entanto, mesmo que você queira que a sessão dure mais tempo, alguns sites não verificam a autenticação do usuário em cada solicitação. Em outras palavras, não há como revogar o cookie de sessão depois de emitido. Isso normalmente leva a sessões curtas, em que o usuário é forçado a fazer login com frequência para que a autenticação possa ser validada novamente, permitindo coisas como uma mudança de senha para invalidar sessões atuais em um período conhecido.
Se você usa essa abordagem, temos uma solução técnica que pode ajudar a revalidar automaticamente o cookie de autenticação sem estado. Ele funciona com um token secundário de longa duração que pode ser usado para atualizar seu cookie de autenticação de curta duração. Aproveitar o novo padrão de service worker nos permite "fazer check-in" regularmente com o token de longa duração, verificar a autenticação do usuário (por exemplo, verificar se ele não alterou as senhas recentemente ou revogou a sessão) e emita novamente um novo cookie de autenticação de curta duração.
Uma proposta prática para migrar para sessões longas seguras na Web
Nesta postagem, descrevemos uma nova técnica que estamos propondo a chamar de 2-Cookie-Handoff (2CH). Esperamos usar este artigo para ouvir o feedback da comunidade sobre se essa abordagem parece positiva e, em caso afirmativo, para trabalhar com o setor na documentação das práticas recomendadas de uso de 2CH.
Os service workers são uma nova tecnologia compatível com vários navegadores, como Chrome, Firefox, Opera e, em breve, também estarão disponíveis no Edge. Eles permitem interceptar todas as solicitações de rede do site usando um ponto de código comum no cliente, sem modificar as páginas atuais. Isso permite configurar um "worker 2CH" para usuários conectados que pode interceptar todas as solicitações de rede que sua página faz e realizar a troca de tokens, assim como os apps para dispositivos móveis fazem.
Na maioria das vezes, o servidor já tem um endpoint usado por apps para dispositivos móveis para receber um novo token de curta duração, normalmente usando o protocolo OAuth. Para ativar o padrão acima na Web, esse endpoint só precisa ser atualizado para entender quando está sendo chamado por um service worker e, em seguida, retornar um novo cookie de sessão de curta duração formatado de uma maneira que outras páginas do site já esperam.
Se o servidor ainda não tiver esse endpoint, ele poderá criar um apenas para o gerenciamento de sessões do navegador.
O padrão de dois tokens com service workers segue o padrão OAuth 2.0 bem de perto. Se você já executou um endpoint de token OAuth, provavelmente poderá reutilizá-lo com service workers para sua autenticação na Web.
Você também pode estar se perguntando o que acontece se o usuário acessar um navegador que não oferece suporte a service workers. Se você implementar a abordagem acima, eles simplesmente não notarão diferenças e continuarão a ter sessões curtas.
Publicamos um exemplo de cliente e back-end. Esperamos que você faça o teste e responda a uma pesquisa sobre o gerenciamento de sessões.