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
eexample.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
eacmerewards.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 sejaror-1
(e nãoror-2
). - Depois de criar uma chave de acesso no
ror-1
ou noror-2
, você poderá fazer a autenticação com ela noror-1
e noror-2
. Comoror-2
especificaror-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
ouror-2
, ela pode ser preenchida automaticamente pelo Chrome emror-1
eror-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.](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=pt-br)
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 credencialoptions
que são transmitidos para anavigator.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.
- Definir
- Após a autenticação:
- Defina
site-1.com
como o ID da RP nooptions
de autenticação. que são transmitidos para a chamada de front-endnavigator.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.
- Defina
Solução de problemas
![Pop-up de mensagem de erro no Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=pt-br)
![Pop-up de mensagem de erro no Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=pt-br)
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.