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 de usuários, mas eles estão sujeitos a sequestro de sessão. As credenciais de sessão vinculadas ao dispositivo (DBSC, na sigla em inglês) adicionam uma camada de segurança baseada em 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 a DBSC funciona e como integrá-la ao seu site.
Como o DBSC funciona
Em um nível alto, o DBSC apresenta 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 atualizar. Esse processo vincula a continuidade da sessão ao dispositivo original.
Se o dispositivo de um usuário não for compatível com o 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
Secure-Session-Registration. - Adicione um endpoint de registro de sessão que:
- Associa uma chave pública à sessão do usuário.
- Veicula a configuração da sessão.
- Transições para cookies de curta duração.
- Adicione um endpoint de atualização para processar a renovação de cookies e a validação da posse de chaves.
A maioria dos seus endpoints atuais não exige mudanças. O DBSC foi projetado para ser aditivo e não disruptivo.
Quando um cookie obrigatório de curta duração está ausente ou expirou, o Chrome pausa a solicitação e tenta atualizar o cookie. Isso permite que o app continue usando as verificações de cookie de sessão usuais para confirmar se o usuário fez login. Como isso corresponde aos 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 descreve as mudanças necessárias no seu sistema de autenticação, incluindo como modificar o fluxo de login, processar o registro de sessões 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 experienciaria quando o DBSC está ativo: registro no login, seguido por 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 à sessão do seu 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 Secure-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
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
Se o dispositivo for compatível com o 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 forma consistente em todo o aplicativo.
2. Implementar o endpoint de registro de sessão
Em /StartSession, seu servidor precisa:
- Associe 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 a seguir, 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 expira, o Chrome inicia um fluxo de atualização para provar a posse da chave privada. Esse processo envolve ações coordenadas do Chrome e do seu 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-Secure-Session-Id: session_idSeu servidor responde com um desafio:
HTTP/1.1 403 Forbidden Secure-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-Secure-Session-Id: session_id Secure-Session-Response: <JWT proof>O servidor valida a prova assinada 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 não DBSC ao lado do 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 não autenticadas e falhas temporárias do DBSC.
- O cookie de longa duração persiste mesmo que o DBSC falhe.
- O cookie de curta duração é atualizado usando o DBSC e é necessário para operações sensíveis.
Esse padrão dá aos sites mais controle sobre como lidar com casos extremos.
Advertências e comportamento de substituição
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 está inacessível devido a erros de rede ou problemas no servidor.
- O TPM está ocupado ou encontra erros de assinatura. Como o TPM é compartilhado entre processos do sistema, atualizações excessivas podem exceder os limites de taxa.
- O cookie de curta duração gerenciado pelo DBSC é 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 ainda houver um. Esse substituto só funciona se a implementação incluir um cookie de longa duração e um 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 aplicativo. Elas oferecem proteção mais forte contra o sequestro de sessão ao vincular sessões a dispositivos específicos. A maioria dos usuários se beneficia sem sofrer interrupções, e o DBSC faz um fallback normal em hardware sem suporte.
Para mais informações, consulte a especificação do DBSC.