As credenciais de sessão vinculadas ao dispositivo (DBSC, na sigla em inglês) reforçam a autenticação adicionando segurança de sessão com suporte de hardware.
Introdução
Muitos sites dependem de cookies de longa duração para autenticação do usuário, mas eles são suscetíveis a invasão de sessão. As credenciais de sessões vinculadas ao dispositivo (DBSC, na sigla em inglês) adicionam uma camada de segurança com suporte de hardware para reduzir esse risco, garantindo que as sessões sejam vinculadas a dispositivos específicos.
Este guia é destinado a desenvolvedores que mantêm fluxos de autenticação em aplicativos da Web. Ele explica como o DBSC funciona e como integrá-lo ao seu site.
Como o DBSC funciona
De forma geral, o DBSC introduz um par de chaves criptográficas associado ao dispositivo do usuário. O Chrome gera esse par de chaves durante o login e armazena a chave privada em hardware seguro, como um módulo de plataforma confiável (TPM), quando disponível. As sessões usam cookies de curta duração. Quando um desses cookies expira, o Chrome prova a posse da chave privada antes de atualizá-los. Esse processo vincula a continuidade da sessão ao dispositivo original.
Se o dispositivo de um usuário não oferecer suporte ao armazenamento seguro de chaves, o DBSC vai voltar ao comportamento padrão sem interromper o fluxo de autenticação.
Visão geral da implementação
Para integrar o DBSC ao seu aplicativo, faça as seguintes mudanças:
- Modifique seu fluxo de login para incluir um cabeçalho
Sec-Session-Registration. - Adicione um endpoint de registro de sessão que:
- Associa uma chave pública à sessão do usuário.
- Fornece a configuração da sessão.
- Transições para cookies de curta duração.
- Adição de um endpoint de atualização para processar a renovação de cookies e a validação de posse de chaves.
A maioria dos endpoints atuais não exige mudanças. O DBSC foi projetado para ser aditivo e não disruptivo.
Quando um cookie de curta duração obrigatório está ausente ou expirou, o Chrome pausa a solicitação e tenta atualizar o cookie. Isso permite que seu app continue usando as verificações normais de cookies de sessão para confirmar se o usuário está conectado. Como isso corresponde a fluxos de autenticação típicos, o DBSC funciona com mudanças mínimas na lógica de login.
Etapas de implementação
Esta seção explica as mudanças necessárias no sistema de autenticação, incluindo como modificar o fluxo de login, processar o registro de sessão e gerenciar atualizações de cookies de curta duração. Cada etapa foi projetada para se integrar perfeitamente à sua infraestrutura atual.
As etapas de implementação seguem o fluxo comum que um usuário conectado passaria quando o DBSC estiver ativo: registro no login, seguido de atualizações regulares de cookies de curta duração. É possível testar e implementar cada etapa de forma independente, dependendo do nível de sensibilidade da sessão do app.
1. Modificar o fluxo de login
Depois que o usuário fizer login, responda com um cookie de longa duração e um
cabeçalho Sec-Session-Registration. Exemplo:
O seguinte cabeçalho de resposta HTTP é retornado após o registro de sessão bem-sucedido:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
Se o dispositivo oferecer suporte ao armazenamento seguro de chaves, o Chrome vai entrar em contato com o endpoint /StartSession
com uma chave pública em um JSON Web Token (JWT).
O auth_cookie neste exemplo representa seu token de sessão. Você pode nomear
esse cookie como quiser, desde que ele corresponda ao campo name na
configuração da sessão e seja usado de maneira consistente em todo o aplicativo.
2. Implementar o endpoint de registro de sessão
Em /StartSession, o servidor precisa:
- Associar a chave pública recebida à sessão do usuário.
- Responda com uma configuração de sessão.
- Substitua o cookie de longa duração por um de curta duração.
No exemplo abaixo, o cookie de curta duração é configurado para expirar após 10 minutos:
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutes Set-Cookie: Domain=example.com; Secure; SameSite=Lax
{
"session_identifier": "session_id",
"refresh_url": "/RefreshEndpoint",
"scope": {
"origin": "https://example.com",
"include_site": true,
"scope_specification": [
{ "type": "exclude", "domain": "*.example.com", "path": "/static" }
]
},
"credentials": [{
"type": "cookie",
"name": "auth_cookie",
"attributes": "Domain=example.com; Secure; SameSite=Lax"
}]
}
3. Implementar o endpoint de atualização
Quando o cookie de curta duração expirar, o Chrome vai iniciar um fluxo de atualização para provar a posse da chave privada. Esse processo envolve ações coordenadas pelo Chrome e pelo servidor:
O Chrome adia a solicitação do usuário para seu aplicativo e envia uma solicitação de atualização para
/RefreshEndpoint:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_idSeu servidor responde com um desafio:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"O Chrome assina o desafio usando a chave privada armazenada e tenta novamente a solicitação:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>O servidor valida o comprovante assinado e emite um cookie de curta duração atualizado:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=LaxO Chrome recebe o cookie atualizado e retoma a solicitação adiada original.
Padrão de integração alternativo
Para melhorar a resiliência, os sites podem adicionar um segundo cookie que não seja DBSC junto com o cookie de curta duração. Esse cookie de longa duração é usado apenas para emitir novos tokens de curta duração e ajuda a distinguir entre solicitações realmente não autenticadas e falhas temporárias do DBSC.
- O cookie de longa duração persiste mesmo se a DBSC falhar.
- O cookie de curta duração é atualizado usando o DBSC e é necessário para operações sensíveis.
Esse padrão oferece aos sites mais controle sobre como lidar com casos extremos.
Advertências e comportamento substituto
O Chrome pode pular operações do DBSC e enviar solicitações sem o cookie de curta duração gerenciado pelo DBSC nos seguintes cenários:
- O endpoint de atualização não pode ser acessado devido a erros de rede ou problemas no servidor.
- O TPM está ocupado ou encontra erros de assinatura. Como o TPM é compartilhado entre os processos do sistema, as atualizações excessivas podem exceder os limites de taxa.
- O cookie de curta duração gerenciado pelo DBSC é um cookie de terceiros, e o usuário bloqueou cookies de terceiros nas configurações do navegador.
Nessas situações, o Chrome volta a usar o cookie de longa duração, se ele ainda estiver presente. Essa alternativa só funciona se a implementação incluir um cookie de longa duração e outro de curta duração. Caso contrário, o Chrome envia a solicitação sem um cookie.
Resumo
As credenciais de sessões vinculadas ao dispositivo melhoram a segurança da sessão com mudanças mínimas no seu app. Elas oferecem proteções mais fortes contra o sequestro de sessão vinculando sessões a dispositivos específicos. A maioria dos usuários se beneficia sem interrupções, e a DBSC é usada em hardware sem suporte.
Para mais informações, consulte a especificação DBSC.