Permitir a reutilização da chave de acesso nos seus sites com solicitações de origem relacionadas

Maud Nalpas

O problema que as solicitações de origem relacionadas resolvem

As chaves de acesso são vinculadas a um site específico e só podem ser usadas para fazer login no site em que foram criadas.

Isso é especificado na parte confiável ID (ID da RP), que para chaves de acesso criadas para o domínio example.com pode ser www.example.com ou example.com.

Embora os IDs da parte restrita impeçam que as chaves de acesso sejam usadas como uma única credencial para autenticando em todos os lugares, eles criam problemas para:

• Sites com vários domínios: os usuários não podem usar a mesma chave de acesso para fazer login em diferentes domínios específicos de países (por exemplo, example.com e example.co.uk) gerenciadas pela mesma empresa.
• Domínios com marca: os usuários não podem usar a mesma credencial no domínios diferentes usados por uma única marca (por exemplo, acme.com e acmerewards.com).
• Aplicativos para dispositivos móveis: os aplicativos para dispositivos móveis geralmente não têm domínio próprio, o que um desafio de gerenciamento de credenciais.

Existem soluções baseadas na federação de identidade e outras baseadas na iframes, mas são inconvenientes em alguns casos. As solicitações de origem relacionadas oferecem uma solução.

Observação :os IDs da parte restrita fazem credenciais separadas entre sites diferentes, mas o phishing vem da verificação da origem do site no campo CollectedClientData.

Solução

Com Solicitações de origem relacionadas, um site pode especificar origens que podem usar o ID da RP.

Isso permite que os usuários reutilizem a mesma chave de acesso em vários sites que você opera.

Para usar solicitações de origem relacionadas, você precisa disponibilizar um arquivo JSON especial em um URL específico https://{RP ID}/.well-known/webauthn. Se example.com quiser permitir que as origens adicionais o usem como um ID da RP, ele deverá veicular o seguinte arquivo em https://example.com/.well-known/webauthn:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

Da próxima vez que qualquer um desses sites solicitar a criação de chaves de acesso, (navigator.credentials.create) ou autenticação (navigator.credentials.get) que usa example.com como um ID da RP, o navegador notará um ID da RP que não corresponde à origem solicitante. Se o navegador oferecer suporte à origem relacionada solicitações, ele primeiro procura um webauthn em https://{RP ID}/.well-known/webauthn. Se o arquivo existir, o navegador verifica se a origem que fez a solicitação está na lista de permissões; . Em caso afirmativo, ele segue para as etapas de criação ou autenticação da chave de acesso. Se o navegador não oferecer suporte a solicitações de origem relacionadas, uma SecurityError será gerada.

Suporte ao navegador

• Chrome: compatível a partir do Chrome 128.
• Safari: compatível com o macOS 15 Beta 3 e com o iOS 18 Beta 3 para dispositivos móveis.
• Firefox: Aguardando posição.

.

Aviso :a partir de agosto de 2024, as solicitações de origem relacionadas não serão mais compatíveis com o Firefox. getClientCapabilities ainda não está disponível para que você detecte o recurso ausente e implemente uma substituto. Se você implementar Solicitações de origem relacionadas, os usuários do Firefox não poderão criar uma chave de acesso (ou fazer login com ela) nos domínios que pretendem usar outro site como um ID da RP e uma SecurityError serão geradas.

Como configurar solicitações de origem relacionadas

A demonstração a seguir usa o exemplo de dois sites, https://ror-1.glitch.me e https://ror-2.glitch.me.
Para permitir que os usuários façam login com a mesma chave de acesso nos dois sites, ele usa as solicitações de origem relacionadas para permitir que ror-2.glitch.me use ror-1.glitch.me como o ID da RP.

Demonstração

Observação: abra a demonstração em um dos navegadores compatíveis.

https://ror-2.glitch.me implementa solicitações de origem relacionadas para usar ror-1.glitch.me como um ID de RP. Assim, ror-1 e ror-2 usam ror-1.glitch.me como um ID de RP ao criar uma chave de acesso ou fazer a autenticação com ela.
Também implementamos um banco de dados de chaves compartilhadas nesses sites.

Observe a seguinte experiência do usuário:

• Você pode criar uma chave de acesso e autenticar com ela no ror-2, mesmo que o ID da RP seja ror-1 (e não ror-2).
• Depois de criar uma chave de acesso no ror-1 ou no ror-2, você poderá fazer a autenticação com ela no ror-1 e no ror-2. Como ror-2 especifica ror-1 como um RP ID, fazer uma solicitação de criação ou autenticação de chave de acesso em qualquer um desses sites é o mesmo que fazer a solicitação em ror-1. O ID da RP é a única coisa que vincula uma solicitação a uma origem.
• Depois que você cria uma chave de acesso em ror-1 ou ror-2, ela pode ser preenchida automaticamente pelo Chrome em ror-1 e ror-2.
• Uma credencial criada em qualquer um desses sites terá o ID da RP de ror-1.

.

Graças às solicitações de origem relacionadas, os usuários podem usar a mesma credencial de chave de acesso na ror-1 e ror-2. O Chrome também vai preencher as credenciais automaticamente.

Ver código:

• Consulte o arquivo ./well-known/webauthn configurado na base de código ror-1 (link em inglês).
• Confira RP_ID_ROR ocorrências na base de código ror-2 (link em inglês).

.

Observação: nesta demonstração, para simplificar, nenhuma verificação de senha acontece internamente. A demonstração se concentra nas chaves de acesso.

Etapa 1: implemente um banco de dados de contas compartilhado

Se você quiser que os usuários possam fazer login com a mesma chave de acesso em site-1 e site-2, implemente um banco de dados de conta compartilhado entre esses dois sites.

Etapa 2: configurar o arquivo JSON .well-known/webauthn no site-1

Primeiro, configure o site-1.com para que ele permita que o site-2.com o use como um ID da parte restrita. Para isso, crie o arquivo JSON webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

O objeto JSON precisa conter origens nomeadas de chave, cujo valor seja uma matriz de um ou mais strings contendo origens da Web.

Limitação importante: máximo de cinco marcadores

Cada elemento dessa lista será processado para extrair o rótulo do eTLD+1. Por exemplo, os rótulos eTLD + 1 de example.co.uk e example.de são ambos example No entanto, o rótulo eTLD + 1 de example-rewards.com é example-rewards. No Chrome, o número máximo de marcadores é cinco.

Aviso: se a lista incluir muitos marcadores (mais de cinco), o excesso elementos serão ignorados.

Etapa 3: disponibilizar o JSON .well-known/webauthn no site-1

Em seguida, disponibilize seu arquivo JSON em site-1.com/.well-known/webauthn.

Atenção: o arquivo precisa ser enviado com um tipo de conteúdo application/json e conter um objeto JSON único que liste as origens permitidas. O formato correto do arquivo é /.well-known/webauthn (não inclua a extensão .json).

Por exemplo, no modo expresso:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Aqui, estamos usando o res.json expresso, que já define o content-type correto ('application/json').

Etapa 4: especificar o ID da parte restrita desejado em site-2

Na base de código site-2, defina site-1.com como o ID da RP em todos os lugares necessários:

• Na criação da credencial:
  • Definir site-1.com como o ID da RP na criação da credencial options que são transmitidos para a navigator.credentials.create chamadas de front-end e, normalmente, são geradas do lado do servidor.
  • Defina site-1.com como o ID da RP esperado ao executar a credencial antes de salvá-los no banco de dados.
• Após a autenticação:
  • Defina site-1.com como o ID da RP no options de autenticação. que são transmitidos para a chamada de front-end navigator.credentials.get e normalmente são geradas do lado do servidor.
  • Defina site-1.com como o ID da RP esperado que será verificado no servidor, conforme você executa verificações de credenciais antes de autenticar o usuário.

.

Observação: e o origin? E o RP name? Na base de código do site-2, o origin esperado precisa permanecer inalterado (https://site-2.com), porque designa onde a solicitação deve de origem. De acordo com o nome do RP (rp.name), ele não é usado na prática. Você pode deixar esse campo em branco.

Solução de problemas

Mensagem de erro no Chrome durante a criação de credenciais. Esse erro será gerado se o arquivo ".well-known/webauthn" não puder ser encontrado em "https://{RP ID}/.well-known/webauthn".

.

Mensagem de erro no Chrome na criação da credencial. Esse erro será gerado se o arquivo ".well-known/webauthn" for encontrado, mas não listar a origem da qual você está tentando criar uma credencial.

Outras considerações

Compartilhar chaves de acesso entre sites e apps para dispositivos móveis

As solicitações de origem relacionadas permitem que seus usuários reutilizem uma chave de acesso em vários de sites. Para permitir que os usuários reutilizem uma chave de acesso em um site e um app para dispositivos móveis, use as seguintes técnicas:

• No Chrome: Digital Asset Links. Saiba mais em Adicionar suporte ao Digital Asset Links.
• No Safari: Domínios associados.

Compartilhar senhas entre sites

Com as solicitações de origem relacionadas, os usuários podem reutilizar uma chave de acesso em vários sites. As soluções para compartilhar senhas entre sites variam de acordo com o gerenciador de senhas. Para o Gerenciador de senhas do Google, use o Digital Asset Links. O Safari tem um sistema diferente.

Papel de gerenciadores de credenciais e user agents

Isso vai além do seu escopo como desenvolvedor de sites, mas observe que, o ID da RP não deve ser um conceito visível ao usuário no user agent ou no gerenciador de credenciais que seus usuários estão usando. Em vez disso, os user agents e as credenciais os gerentes devem mostrar aos usuários onde as credenciais deles foram usadas. Essa mudança vai levar algum tempo para ser implementada. Uma solução temporária seria exibir site atual e o site original de registro.