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. Oferta de solicitações de origem relacionadas e desenvolve uma solução.

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 uma 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.

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

https://ror-2.glitch.me (link em inglês) implementa solicitações de origem relacionadas para usar ror-1.glitch.me como um ID da RP, então ror-1 e ror-2 usam ror-1.glitch.me como um ID da RP ao criar uma chave de acesso ou autenticar com ela.
Também implementamos um banco de dados de chaves de acesso 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 ID da RP, fazer uma solicitação de criação de chave de acesso ou de autenticação em qualquer um desses sites é o mesmo que fazer a solicitação na 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.

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).

Etapa 1: implemente um banco de dados de contas compartilhado

Se você quiser que seus usuários possam fazer login com a mesma chave de acesso site-1 e site-2, implementam um banco de dados de contas compartilhado entre essas 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 eTLD + 1 rótulo. 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.

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

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

Por exemplo, no modo expresso:

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

Estamos usando o res.json expresso, que já define a 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:

• Após a 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 chamada de front-end e normalmente geradas no 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.

Solução de problemas

.

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, faça o seguinte: 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 levaria algum tempo para ser implementado. Uma solução temporária seria exibir site atual e o site original de registro.