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

Maud Nalpas
Maud Nalpas

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.

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

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 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.
.
O Chrome faz o preenchimento automático nos dois sites.
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:

.

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.

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);
});

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

Solução de problemas

Pop-up de mensagem de erro no Chrome.
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".
.
Pop-up de mensagem de erro no Chrome.
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:

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.