Adoramos a forma como os aplicativos nativos pedem para você fazer login apenas uma vez e 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, com mais sites enviando todo o tráfego por HTTPS, reduzindo o risco de roubo de token, os sites precisam reconsiderar as políticas de cookies de curta duração e adotar sessões mais fáceis de usar e mais longas.
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 ações como uma mudança de senha para invalidar sessões existentes em um período conhecido.
Se essa for uma abordagem que você usa, temos uma solução técnica que pode ajudar a revalidar automaticamente o cookie de autenticação sem estado. Ela funciona com um token secundário de longa duração que pode ser usado para atualizar o cookie de autenticação de curta duração atual. Aproveitar o novo padrão de service worker permite fazer verificações regulares com o token de longa duração, verificar a autenticação do usuário (por exemplo, conferir 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 de migração para sessões longas e seguras na Web
Nesta postagem, descrevemos uma nova técnica que propomos 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 da 2CH.
Os service workers são uma nova tecnologia compatível com vários navegadores, como Chrome, Firefox e Opera, e em breve estará disponível no Edge. Eles permitem que você intercepte todas as solicitações de rede do site por meio de um ponto de código comum no cliente, sem modificar as páginas existentes. Isso permite configurar um "worker de 2CH" para usuários conectados que podem interceptar todas as solicitações de rede que sua página está fazendo 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, geralmente usando o protocolo OAuth. Para ativar o padrão acima na Web, esse endpoint só precisa ser atualizado para entender quando ele 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 muito de perto. Se você já executa um endpoint de token OAuth, provavelmente pode 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 visitar um navegador que não oferece suporte a service workers. Se você implementar a abordagem acima, eles simplesmente não notarão diferença e continuarão a ter sessões curtas.
Publicamos um cliente de amostra e um back-end. Esperamos que você faça um teste e responda a uma pesquisa sobre gerenciamento de sessões.