---
url: 'https://www.corbado.com/pt/blog/webauthn-origens-relacionadas-passkeys-entre-dominios'
title: 'WebAuthn Related Origins: Guia de Passkeys entre Domínios'
description: 'Aprenda como as Solicitações de Origem Relacionada do WebAuthn permitem o uso de passkeys em múltiplos domínios. Um guia completo de implementação com exemplos do mundo real.'
lang: 'pt'
author: 'Vincent Delitz'
date: '2025-10-31T14:41:25.898Z'
lastModified: '2026-03-25T10:03:59.759Z'
keywords: 'origens relacionadas, webauthn origens relacionadas, solicitação de origem relacionada, passkeys entre domínios, .well-known/webauthn, ROR'
category: 'WebAuthn Know-How'
---

# WebAuthn Related Origins: Guia de Passkeys entre Domínios

## 1. Introdução: Quebrando as Fronteiras Digitais para as Passkeys

As Passkeys são o novo padrão para [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) segura e
fácil de usar. Construídas sobre os padrões [FIDO](https://www.corbado.com/pt/glossary/attestation)/WebAuthn,
elas utilizam
[criptografia de chave pública](https://www.corbado.com/pt/blog/webauthn-pubkeycredparams-credentialpublickey)
para oferecer resistência inerente a [phishing](https://www.corbado.com/glossary/phishing) e
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing), melhorando drasticamente a postura
de segurança e, ao mesmo tempo, simplificando a experiência de login para os usuários.
Para as organizações, isso se traduz em benefícios comerciais tangíveis: redução de custos
operacionais com redefinições de senha e OTPs por SMS, mitigação de riscos financeiros de
fraudes de apropriação de contas e aumento de receita por meio de maiores taxas de
conversão.

No entanto, uma das maiores forças de segurança do WebAuthn — sua natureza estrita e
vinculada à origem — cria um desafio significativo no mundo real para marcas globais e
empresas com diversas presenças digitais. Por design, uma passkey criada para um domínio
web específico é criptograficamente bloqueada para esse domínio, um princípio fundamental
que previne ataques de [phishing](https://www.corbado.com/glossary/phishing). Embora seja um recurso de segurança
poderoso, isso leva a uma experiência de usuário fragmentada e confusa quando uma única
marca opera em múltiplos domínios.

Um exemplo proeminente desse desafio é a mudança de marca do
[Twitter](https://www.corbado.com/blog/x-twitter-passkeys) para X. Um usuário que criou uma passkey em
[twitter](https://www.corbado.com/blog/x-twitter-passkeys).com a acharia inutilizável em x.com, forçando a
empresa a implementar redirecionamentos complicados ou exigir que os usuários se registrem
novamente, criando um atrito que dificulta diretamente a adoção. Este não é um problema
isolado. Grandes empresas como a Amazon operam em vários domínios de topo de código de
país (ccTLDs), como amazon.com, amazon.de e amazon.co.uk, todos compartilhando um sistema
de contas de usuário comum. Em um mundo pré-passkeys, os gerenciadores de senhas lidam
habilmente com essa complexidade, mas o comportamento padrão do WebAuthn exigiria uma
passkey separada para cada domínio, frustrando os usuários e minando a promessa de um
login contínuo.

Para resolver esse bloqueador crítico de adoção, o W3C introduziu um novo recurso no
padrão WebAuthn: as **Solicitações de Origem Relacionada (ROR)**. Este poderoso mecanismo
fornece uma
[maneira padronizada e segura](https://developer.chrome.com/blog/passkeys-updates-chrome-129)
para um conjunto de domínios confiáveis compartilhar uma única passkey, criando uma
experiência de [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) unificada e contínua em todo o
ecossistema digital de uma marca. Esta análise aprofundada explora os fundamentos técnicos
do [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys), fornece um guia prático
para sua implementação e analisa suas implicações estratégicas para a arquitetura de
[autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) moderna.

A introdução do [ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) marca um
amadurecimento significativo do padrão WebAuthn. As especificações iniciais priorizaram o
estabelecimento de
[princípios criptográficos e de segurança fundamentais](https://www.w3.org/TR/webauthn-3/),
com a vinculação estrita de uma credencial a um ID de Parte Confiável (rpID) sendo um
pilar de seu design anti-[phishing](https://www.corbado.com/glossary/phishing). À medida que implantações
empresariais de grande escala por empresas como Amazon e Google se tornaram realidade, o
atrito prático causado por essa rigidez ficou aparente. Esse atrito é um impedimento
direto para alcançar uma alta adoção pelos usuários, que é a medida final de sucesso para
qualquer projeto de passkeys. O desenvolvimento do
[ROR](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) é uma resposta direta a esse
feedback empresarial, demonstrando uma evolução pragmática do padrão. Ele reconhece que,
para um protocolo de segurança alcançar sucesso generalizado, sua usabilidade deve ser
dimensionada para acomodar as complexas realidades de negócios e estratégias de marca das
organizações que o implementam.

Este guia abrangente responde a cinco perguntas críticas para a implementação de
Solicitações de Origem Relacionada do WebAuthn:

1. **Por que as passkeys falham em múltiplos domínios?** Entendendo o modelo de segurança
   do WebAuthn vinculado à origem e seus pontos de atrito no mundo real.
2. **Como as Solicitações de Origem Relacionada funcionam tecnicamente?** Uma análise
   aprofundada do fluxo de validação do navegador e do mecanismo de URI .well-known.
3. **O que é necessário para implementar o ROR?** Configuração passo a passo no servidor e
   no cliente com exemplos práticos de código.
4. **Quando você deve escolher o ROR em vez do login federado?** Um framework de decisão
   estratégica comparando o ROR com abordagens OIDC/SAML.
5. **Como lidar com a compatibilidade de navegadores e considerações de segurança?**
   Matriz de suporte atual e melhores práticas de segurança.

Para mais detalhes técnicos, consulte o
[Explicador Oficial de Solicitações de Origem Relacionada do WebAuthn](https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests).

## 2. O Problema Fundamental: O Relying Party ID e o Escopo de Origem do WebAuthn

Para apreciar plenamente a elegância da solução de Solicitações de Origem Relacionada, é
essencial primeiro entender os conceitos técnicos subjacentes que necessitam de sua
existência: a Política de Mesma Origem da web e as regras de escopo do
[Relying Party](https://www.corbado.com/glossary/relying-party) ID (rpID) do WebAuthn. Esses mecanismos são
fundamentais para a segurança da web, mas criam o próprio atrito que o ROR foi projetado
para aliviar.

### 2.1 Origem da Web e a Política de Mesma Origem

Uma "origem" da web é um conceito de segurança crítico definido pela combinação única do
protocolo (ex: https), domínio (ex: app.example.com) e porta (ex: 443) de onde o conteúdo
é servido. A
[**Política de Mesma Origem**](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)
é um mecanismo de segurança aplicado pelos navegadores que restringe como um script
carregado de uma origem pode interagir com um recurso de outra. É um elemento importante
da segurança da web, isolando efetivamente documentos potencialmente maliciosos e
impedindo que um site fraudulento, por exemplo, leia dados sensíveis da sessão de webmail
autenticada de um usuário em outra aba.

### 2.2 Relying Party ID (rpID)

No ecossistema WebAuthn, a "Parte Confiável" (RP) é o site ou aplicativo com o qual um
usuário está tentando se autenticar. Cada passkey é criptograficamente vinculada a um
**Relying Party ID (rpID)** no momento de sua criação. O rpID é um nome de domínio que
define o escopo e o limite para essa credencial.

Por padrão, o rpID é o domínio efetivo da origem onde a passkey está sendo criada. As
regras de escopo do WebAuthn permitem que uma origem defina um rpID que seja igual ao seu
próprio domínio ou a um sufixo de domínio registrável. Por exemplo, um script em execução
em `https://www.accounts.example.co.uk` pode
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) com um rpID de:

- `www.accounts.example.co.uk` (o domínio completo)
- `accounts.example.co.uk`
- `example.co.uk`

Essa flexibilidade permite que uma passkey criada em um subdomínio seja usada em outros
subdomínios do mesmo domínio pai, o que é um padrão comum e necessário. No entanto, as
regras proíbem estritamente a definição de um rpID que não seja um sufixo. O mesmo script
em `www.accounts.example.co.uk` _não_ poderia
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) com um rpID de
`example.com`, porque `.com` é um domínio de topo diferente.

Essa vinculação estrita serve a um propósito importante: separar as credenciais por escopo
de domínio. Uma passkey criada para `mybank.com` não pode ser exercida em
`phishing-site.com` porque o site malicioso não pode reivindicar o rpID legítimo de
`mybank.com`. O navegador nem sequer apresentará a passkey como uma opção.

No entanto, **o rpID em si não é o principal controle anti-phishing**. A proteção
anti-phishing do WebAuthn, na verdade, vem da **verificação de origem** no objeto
[clientDataJSON](https://www.corbado.com/glossary/clientdatajson). Durante cada cerimônia WebAuthn, o navegador
cria um objeto JSON contendo contexto crítico, incluindo a _origem exata_ que iniciou a
solicitação. Este objeto inteiro é então criptograficamente assinado pela chave privada do
autenticador. O servidor (Parte Confiável) **DEVE verificar** essa assinatura e,
crucialmente, **validar que o campo de origem no clientDataJSON assinado corresponde a um
valor esperado e confiável**. Essa verificação de origem é o que previne ataques de
phishing.

Com as Solicitações de Origem Relacionada, o escopo do rpID é relaxado — permitindo que
`bar.com` reivindique legitimamente o rpID de `foo.com` após o navegador validar o arquivo
`.well-known/webauthn` — mas o requisito de verificação de origem permanece inalterado. O
[clientDataJSON](https://www.corbado.com/glossary/clientdatajson) ainda informará veridicamente a origem como
`bar.com`. O servidor em `foo.com` recebe esses dados assinados, verifica-os e vê que a
solicitação veio de `bar.com`. O servidor deve então verificar se `bar.com` é uma origem
relacionada esperada antes de aceitar a autenticação. Isso demonstra uma abordagem
multicamadas que permite maior flexibilidade sem sacrificar o princípio central da
verificação de origem.

## 3. A Solução: Como Funcionam as Solicitações de Origem Relacionada

O mecanismo de Solicitações de Origem Relacionada introduz uma maneira elegante e
padronizada para que os domínios declarem publicamente uma relação de confiança com o
propósito de compartilhar passkeys. Ele aproveita um padrão web bem estabelecido — o URI
`/.well-known/` — para criar uma "lista de permissões" verificável e legível por máquina
que os navegadores podem consultar.

O conceito central é simples: um domínio que serve como o rpID primário e canônico para um
conjunto de sites relacionados pode hospedar um arquivo JSON especial em uma URL
padronizada e "bem conhecida": `https://{rpID}/.well-known/webauthn`. Este arquivo atua
como um manifesto público, listando explicitamente todas as outras origens que estão
oficialmente autorizadas a criar e usar passkeys sob esse rpID primário.

O fluxo de validação do navegador é acionado sempre que encontra uma incompatibilidade
entre a origem atual e o rpID solicitado:

1. Um usuário em um site "relacionado", como `https://example.co.uk`, inicia uma operação
   de passkey (criação ou autenticação) onde o código do lado do cliente especifica um
   domínio diferente como rpID, por exemplo, `example.com`.
2. O navegador detecta essa incompatibilidade. Sob as regras antigas, isso resultaria
   imediatamente em um [SecurityError](https://www.corbado.com/blog/webauthn-errors).
3. Com o suporte a ROR, o navegador, antes de falhar, faz uma solicitação HTTPS GET segura
   para a URL bem conhecida do rpID _reivindicado_:
   `https://example.com/.well-known/webauthn`. Esta solicitação é feita sem credenciais de
   usuário (como cookies) e sem um cabeçalho de referenciador para proteger a privacidade
   do usuário e evitar rastreamento.
4. O navegador recebe a resposta JSON do servidor. Ele analisa o arquivo e verifica se a
   origem atual (`https://example.co.uk`) está presente no array `origins` dentro do
   objeto JSON.
5. Se a origem for encontrada na lista de permissões, a operação WebAuthn pode prosseguir
   usando `example.com` como o rpID válido. Se a origem não for encontrada, ou se o
   arquivo estiver ausente ou malformado, a operação falha como teria falhado
   anteriormente.

A escolha de usar um URI `/.well-known/` é deliberada e alinha o ROR com padrões web
estabelecidos para descoberta de serviços e validação de controle de domínio. Este caminho
de URI, definido pela RFC 8615, já é usado por vários protocolos críticos, incluindo o
acme-challenge para a emissão de certificados SSL da Let's Encrypt e `assetlinks.json`
para vincular sites a aplicativos [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Ao
adotar essa convenção, o W3C aproveita um padrão que implica inerentemente a propriedade
do domínio. Para colocar um arquivo neste caminho específico e padronizado, é preciso ter
controle administrativo sobre o servidor web para esse domínio. Isso fornece uma prova de
controle simples, mas eficaz, tornando a declaração de confiança verificável. Quando o
proprietário de `example.com` serve um arquivo listando `example.co.uk` como uma origem
relacionada, é uma reivindicação verificável. Esta abordagem nativa da web é muito mais
simples e robusta do que alternativas que foram consideradas e rejeitadas durante o
processo de padronização, como o uso de chaves criptográficas para assinar autorizações
(RP Keys) ou identificadores aleatórios não baseados em domínio (RP UUIDs). O ROR baseia a
relação de confiança no modelo de controle de domínio existente e bem compreendido da web.

## 4. Guia Prático de Implementação para Origens Relacionadas

A implementação de Solicitações de Origem Relacionada requer mudanças coordenadas tanto no
lado do servidor, para autorizar as origens, quanto no lado do cliente, para invocar o
rpID compartilhado. Esta seção fornece o código prático e os detalhes de configuração
necessários para habilitar uma experiência de passkey unificada em todos os seus domínios.

### 4.1 Lado do Servidor: Autorizando Origens com .well-known/webauthn

O servidor que hospeda o rpID primário é responsável por publicar a lista de permissões de
origens relacionadas.

#### 4.1.1 Localização e Formato do Arquivo

O arquivo de autorização deve ser colocado no caminho exato `/.well-known/webauthn` em
relação à raiz do domínio do rpID primário. É crucial que este arquivo seja servido sob as
seguintes condições:

- **Protocolo:** Deve ser servido sobre HTTPS.
- **Content-Type:** O cabeçalho de resposta HTTP Content-Type deve ser definido como
  `application/json`.
- **Extensão do Arquivo:** A URL não deve incluir uma extensão `.json`. O caminho correto
  é `/webauthn`, não `/webauthn.json`.

#### 4.1.2 Estrutura JSON

O arquivo deve conter um único objeto JSON com uma chave, `origins`, cujo valor é um array
de strings. Cada string no array é a origem completa (protocolo, domínio e porta opcional)
que está sendo autorizada.

```json
{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}
```

**Exemplo:** Para um rpID de `example.com`, o arquivo deve ser servido em
`https://example.com/.well-known/webauthn` (nota: sem extensão `.json`).

### 4.2 Lado do Cliente: Invocando um rpID compartilhado

Uma vez que o servidor esteja configurado com o arquivo `.well-known/webauthn`, todos os
domínios relacionados devem usar consistentemente o mesmo rpID compartilhado em suas
chamadas de API WebAuthn. Essa coordenação é crítica para que o ROR funcione corretamente.

**Requisitos chave de coordenação:**

1. **Responsabilidade do Backend:** O servidor gera o desafio criptográfico e especifica o
   rpID compartilhado tanto nas solicitações de criação de credencial quanto nas de
   autenticação.
2. **Responsabilidade do Frontend:** Todos os aplicativos clientes (`example.com`,
   `example.co.uk`, `example.de`) devem passar o mesmo rpID compartilhado para a API
   `navigator.credentials` do navegador.
3. **Gerenciamento de Configuração:** O rpID compartilhado deve ser tratado como um valor
   de configuração global crítico, aplicado consistentemente em todos os sites
   relacionados.

Uma configuração incorreta em apenas um site — onde ele usa sua própria origem como rpID
em vez do valor compartilhado — quebrará a experiência de passkey unificada para os
usuários nesse domínio.

**Importante:** O servidor **DEVE** verificar o campo `origin` no
[clientDataJSON](https://www.corbado.com/glossary/clientdatajson) para cada solicitação, garantindo que ele
corresponda a uma das origens relacionadas autorizadas. Essa verificação de origem é o
principal mecanismo de proteção contra phishing.

## 5. Recomendação: Escolha ROR para Experiências de Marca Unificadas, OIDC para SSO Verdadeiro

**As Solicitações de Origem Relacionada (ROR) e os protocolos de identidade federada
(OIDC/SAML) resolvem problemas diferentes.** O ROR não é um substituto para o
[Single Sign-On](https://www.corbado.com/blog/passkeys-single-sign-on-sso) — é um complemento que aborda um caso
de uso específico e restrito.

### 5.1 Quando usar Solicitações de Origem Relacionada

O ROR é apropriado para **uma única aplicação lógica** distribuída em múltiplos domínios
relacionados que compartilham o mesmo banco de dados de usuários:

- Uma única marca operando em múltiplos TLDs de código de país (ex: `amazon.com`,
  `amazon.de`, `amazon.co.uk`)
- Todos os domínios compartilham o mesmo sistema de autenticação de backend e banco de
  dados de usuários
- Você quer evitar fluxos baseados em redirecionamento e manter a autenticação contextual
  a cada domínio
- Seus domínios se enquadram no limite de 5 rótulos
- Os usuários devem experimentar todos os domínios como um serviço coeso

**O que o ROR oferece:** A mesma passkey funciona em todos os domínios relacionados,
eliminando a necessidade de os usuários criarem passkeys separadas para cada site
regional.

### 5.2 Quando usar Login Federado (OIDC/SAML)

Use protocolos de identidade federada para **Single Sign-On verdadeiro entre aplicações
distintas**:

- Múltiplos serviços com bancos de dados de usuários ou sistemas de identidade separados
- Cenários empresariais onde os usuários precisam de acesso a muitas aplicações diferentes
  (Salesforce, Office 365, ferramentas internas)
- Integração com aplicações de terceiros
- Você precisa de controle de acesso centralizado, trilhas de auditoria e governança de
  identidade
- Você excede o limite de 5 rótulos para origens relacionadas

**O que OIDC/SAML oferecem:** Autenticação centralizada onde os usuários fazem login uma
vez em um Provedor de Identidade (IdP) e obtêm acesso a múltiplos Provedores de Serviço
(SPs) por meio de tokens seguros.

**Importante:** As passkeys podem ser usadas com ambas as abordagens. Você pode
[implementar passkeys](https://www.corbado.com/pt/blog/tutorial-passkeys-como-implementar-em-apps-web) em um IdP
centralizado para [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) federado, ou usar ROR para uma
aplicação única multidomínio. Escolha com base na sua arquitetura, não no seu método de
autenticação.

## 6. Considerações Estratégicas para a Sua Arquitetura de Passkeys

Embora o ROR seja uma solução técnica poderosa, sua implementação deve ser uma decisão
estratégica deliberada. Arquitetos e gerentes de produto devem ponderar seus benefícios em
relação a padrões alternativos e entender suas limitações para construir um sistema de
autenticação robusto e à prova de futuro.

### 6.1 Entendendo o Limite de 5 Rótulos

Uma restrição chave do ROR é o "limite de rótulos". Um "rótulo" neste contexto se refere
ao domínio de topo efetivo mais um nível (eTLD+1), que é a parte registrável de um nome de
domínio. Por exemplo:

- `shopping.com`, `shopping.co.uk` e `shopping.ca` todos compartilham o único rótulo
  **"shopping"**
- `myshoppingrewards.com` introduz um novo e distinto rótulo: **"myshoppingrewards"**
- `travel.shopping.com` ainda se enquadra no rótulo **"shopping"**

**A especificação WebAuthn Nível 3 exige que as implementações de navegadores suportem um
mínimo de cinco rótulos únicos na lista `origins`.** Em 2025, **nenhum navegador conhecido
suporta mais do que este mínimo de cinco rótulos**. Portanto, as organizações devem
projetar suas implantações de ROR com este limite rígido em mente — **trate cinco como o
máximo efetivo**.

Este limite é um mecanismo antiabuso deliberado, projetado para prevenir o uso indevido.
Ele impede entidades como provedores de hospedagem compartilhada (ex: `wordpress.com`) de
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) universal que poderia
funcionar em milhares de subdomínios de clientes não relacionados, o que minaria o modelo
de segurança.

Para a maioria das organizações, mesmo grandes marcas multinacionais, este limite de cinco
rótulos é suficiente. Por exemplo, os vários TLDs de código de país da Amazon
(`amazon.com`, `amazon.de`, `amazon.co.uk`, etc.) todos compartilham o rótulo "amazon",
deixando quatro espaços de rótulo adicionais disponíveis para outras marcas em seu
portfólio, como "audible" ou "zappos".

### 6.2 Estratégias de Implantação: Sistemas Novos vs. Existentes

A complexidade de implementar o ROR depende muito de se ele está sendo introduzido em um
sistema novo ou adaptado a um existente.

- **Implantações Novas (Greenfield):** Para novos projetos, a estratégia é direta. Um
  único domínio canônico deve ser escolhido como o rpID compartilhado desde o início (ex:
  o domínio `.com` primário). Este rpID deve então ser usado consistentemente na
  configuração de todos os sites e aplicativos relacionados desde o primeiro dia.
- **Implantações Existentes:** Adaptar o ROR a um sistema que já possui passkeys
  implantadas com diferentes rpIDs em seus domínios é significativamente mais complexo.
  Uma migração direta não é possível, pois as passkeys existentes estão permanentemente
  vinculadas aos seus rpIDs originais. A abordagem recomendada neste cenário é implementar
  um fluxo de login "identifier-first" (identificador primeiro). O usuário é primeiro
  solicitado a inserir seu nome de usuário ou e-mail. O backend então realiza uma busca
  para determinar a qual rpID sua passkey existente está associada. Finalmente, o usuário
  é redirecionado para a origem correta correspondente a esse rpID para completar a
  cerimônia de autenticação. Após um login bem-sucedido, eles podem ser redirecionados de
  volta ao seu site original. Esta é uma empreitada arquitetônica considerável que requer
  planejamento e implementação cuidadosos.

## 7. Exemplos do Mundo Real: Como Grandes Marcas Implementam Origens Relacionadas

Entender como empresas estabelecidas implementam Solicitações de Origem Relacionada
fornece insights valiosos para sua própria estratégia de implantação. Abaixo estão
exemplos baseados em implementações reais (dados de outubro de 2025):

### 7.1 Implementação da Microsoft

A Microsoft usa ROR para sua [infraestrutura](https://www.corbado.com/passkeys-for-critical-infrastructure) de
autenticação. A configuração real em `login.microsoftonline.com` inclui:

```json
// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}
```

Esta abordagem conservadora permite o compartilhamento de passkeys entre os portais de
login empresarial e de consumidor da Microsoft, mantendo um perímetro de segurança focado.

### 7.2 Implementação da Shopify

A [Shopify](https://www.corbado.com/blog/shopify-passkeys) implementa ROR para unificar a autenticação em
domínios selecionados:

```json
// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}
```

Esta configuração permite que a [Shopify](https://www.corbado.com/blog/shopify-passkeys) conecte sua plataforma
principal com seu aplicativo Shop, demonstrando uma abordagem focada em origens
relacionadas.

### 7.3 Implementação da Amazon

A Amazon tem um arquivo bem grande:

```json
// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}
```

Este padrão permitiria que uma marca fornecesse autenticação unificada de passkey em
domínios regionais, usando o domínio `.com` primário como o rpID.

### 7.4 Padrões de Implementação e Melhores Práticas

Esses exemplos do mundo real revelam vários padrões chave:

1. **Domínio Primário como rpID**: Todas as empresas usam seu domínio .com primário como o
   rpID canônico.
2. **Agrupamento Lógico**: As origens são agrupadas por função de negócio em vez de
   arquitetura técnica.
3. **Escopo Conservador**: A maioria das implementações fica bem abaixo do limite de 5
   rótulos, normalmente usando de 3 a 4 origens.
4. **Estratégia de Subdomínio**: Muitos usam subdomínios do domínio primário para manter a
   consistência da marca.

## 8. Suporte de Navegadores e Postura de Segurança

Como um padrão web moderno, o ROR foi projetado com a segurança como consideração primária
e está sendo ativamente adotado pelos principais navegadores.

### 8.1 Modelo de Segurança

As Solicitações de Origem Relacionada não comprometem as garantias anti-phishing centrais
do WebAuthn. O mecanismo é cuidadosamente projetado para manter uma forte postura de
segurança:

- **Verificação de Origem:** Conforme discutido, o navegador ainda inclui a verdadeira
  origem da solicitação no clientDataJSON assinado. O servidor da Parte Confiável DEVE
  verificar esta origem para garantir que a solicitação venha de uma fonte esperada,
  impedindo que uma origem relacionada comprometida se passe por outra.
- **Busca Segura (Secure Fetch):** A solicitação do navegador ao arquivo
  `.well-known/webauthn` é feita sobre HTTPS. Além disso, a especificação exige que essa
  busca seja realizada sem credenciais (ex: cookies) e sem um cabeçalho Referer. Isso
  impede que a solicitação seja usada para vazar informações do usuário ou para fins de
  rastreamento entre sites.
- **Segurança do Servidor:** O próprio arquivo `.well-known/webauthn` torna-se um ativo de
  segurança crítico. Um invasor que obtenha controle do servidor web que hospeda o rpID
  primário poderia potencialmente modificar este arquivo para adicionar seu próprio
  domínio malicioso à lista de permissões. Portanto, proteger a
  [infraestrutura](https://www.corbado.com/passkeys-for-critical-infrastructure) que serve este arquivo é de suma
  importância.

### 8.2 Suporte de Navegadores e Plataformas

As Solicitações de Origem Relacionada são um recurso da especificação
[WebAuthn Nível 3](https://www.corbado.com/pt/blog/passkeys-prf-webauthn-criptografia-ponta-a-ponta). O suporte
dos navegadores começou a ser lançado no final de 2024:

| **Sistema Operacional** | **Navegador / Plataforma**    | **Versão Suportada**  | **Status**       |
| ----------------------- | ----------------------------- | --------------------- | ---------------- |
| Android                 | Chrome, Edge                  | 128+                  | ✅ Suportado     |
| Chrome OS               | Chrome, Edge                  | 128+                  | ✅ Suportado     |
| iOS / iPadOS            | Todos os Navegadores (Safari) | iOS 18+               | ✅ Suportado     |
| macOS                   | Chrome, Edge                  | 128+                  | ✅ Suportado     |
| macOS                   | Safari                        | Safari 18 (macOS 15+) | ✅ Suportado     |
| Ubuntu                  | Chrome, Edge                  | 128+                  | ✅ Suportado     |
| Windows                 | Chrome, Edge                  | 128+                  | ✅ Suportado     |
| Todas as Plataformas    | Firefox                       | Não suportado         | ⚠️ Usar fallback |

**Fatos importantes:**

- **Chrome e Edge:** Adicionaram suporte a ROR na versão 128 (agosto de 2024)
- **Safari:** Adicionou suporte a ROR no
  [Safari 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades), disponível no macOS 15 e
  [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades) (setembro de 2024)
- **Firefox:** Sem suporte atual para ROR; detecte o recurso e implemente fluxos de
  fallback

### Detecção de Recurso e Fallback

Para aplicações que precisam suportar navegadores mais antigos ou o Firefox, implemente
uma estratégia de fallback:

1. **Detecção de recurso:** Verifique o suporte a ROR usando
   `PublicKeyCredential.getClientCapabilities()`
2. **Fluxo identifier-first:** Peça nome de usuário/e-mail, procure o rpID associado ao
   usuário e, em seguida, redirecione para a origem apropriada para autenticação
3. **Degradação graciosa:** Permita que os usuários criem passkeys separadas por domínio
   se o ROR não estiver disponível

Dados baseados nas matrizes de suporte atuais em outubro de 2025.

## 9. Como a Corbado Pode Ajudar

A implementação de Solicitações de Origem Relacionada requer uma coordenação cuidadosa
entre múltiplas equipes técnicas e um profundo conhecimento dos protocolos WebAuthn. A
plataforma de [adoção de passkeys](https://www.corbado.com/pt/blog/passkeys-adocao-business-case) da Corbado
elimina essa complexidade, fornecendo soluções prontas para empresas para implantações de
passkeys multidomínio.

### 9.1 Implementação Simplificada de ROR

A Corbado lida com a complexidade técnica das Solicitações de Origem Relacionada através
de:

- **Configuração Automatizada**: Nossa plataforma gera e hospeda automaticamente os
  arquivos `.well-known/webauthn` necessários com cabeçalhos de segurança adequados e
  formatação JSON
- **Painel Multidomínio**: Interface de gerenciamento centralizada para configurar origens
  relacionadas em todo o seu portfólio de domínios
- **Ferramentas de Validação**: Testes e validação integrados para garantir que sua
  configuração ROR funcione corretamente em todos os navegadores e plataformas

### 9.2 Segurança e Conformidade de Nível Empresarial

Além da implementação técnica, a Corbado fornece a estrutura de segurança que as empresas
precisam:

- **Verificação de Origem**: Validação automática das origens do clientDataJSON para
  prevenir abuso de domínios relacionados
- **Registro de Auditoria**: Rastreamento abrangente do uso de passkeys em todos os
  domínios relacionados para conformidade e monitoramento de segurança
- **Resposta a Incidentes**: Alertas em tempo real e respostas automatizadas para
  tentativas suspeitas de autenticação entre domínios

### 9.3 Suporte à Migração e Integração

Para organizações com implantações de passkeys existentes, a Corbado oferece:

- **Ferramentas de Migração de Legado**: Análise automatizada das configurações de rpID
  existentes e recomendações de caminhos de migração
- **Fluxos Identifier-First**: Componentes de login pré-construídos que lidam com cenários
  complexos de múltiplos rpIDs durante os períodos de transição
- **Integração de API**: APIs RESTful e SDKs que se integram perfeitamente à sua
  [infraestrutura](https://www.corbado.com/passkeys-for-critical-infrastructure) de autenticação existente

### 9.4 Começando

Pronto para implementar Solicitações de Origem Relacionada para sua organização? A equipe
de especialistas da Corbado pode ajudá-lo a projetar e implantar uma experiência de
passkey unificada em todo o seu ecossistema digital.
[Entre em contato com nossa equipe de soluções](https://www.corbado.com/contact) para
discutir seus requisitos e cronograma específicos.

## 10. Conclusão: Um Futuro Contínuo para Passkeys Multidomínio

A promessa das passkeys reside em sua capacidade de entregar um futuro que é ao mesmo
tempo mais seguro e notavelmente mais simples para os usuários. No entanto, para que este
futuro se torne realidade em escala global, o padrão deve acomodar as complexidades
arquitetônicas das marcas digitais modernas. O atrito criado por passkeys estritamente
vinculadas a domínios tem sido um bloqueador significativo para a adoção por organizações
com presenças online multifacetadas.

As Solicitações de Origem Relacionada do WebAuthn fornecem a solução padronizada, segura e
elegante para este problema. Ao permitir que uma única passkey funcione perfeitamente em
um conjunto confiável de domínios relacionados, o ROR elimina um grande ponto de confusão
e frustração para o usuário.

Este guia abordou cinco questões críticas para a implementação de Solicitações de Origem
Relacionada do WebAuthn:

1. **Por que as passkeys falham em múltiplos domínios?** O modelo de segurança do
   WebAuthn, vinculado à origem, bloqueia criptograficamente as passkeys a domínios
   específicos para prevenir phishing, mas isso cria atrito quando as marcas operam em
   múltiplos domínios, como diferentes TLDs de países.
2. **Como as Solicitações de Origem Relacionada funcionam tecnicamente?** O ROR usa um
   arquivo `.well-known/webauthn` padronizado para criar uma lista de permissões
   verificável de domínios relacionados, permitindo que os navegadores validem o uso de
   passkeys entre domínios por meio de um processo de busca HTTPS seguro.
3. **O que é necessário para implementar o ROR?** A implementação requer a configuração no
   lado do servidor do arquivo de manifesto `.well-known/webauthn` e a coordenação no lado
   do cliente para usar um rpID compartilhado de forma consistente em todas as origens
   relacionadas.
4. **Quando você deve escolher o ROR em vez do login federado?** Use o ROR para
   experiências de marca unificadas em domínios relacionados com bancos de dados de
   usuários compartilhados; use OIDC/SAML para [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)
   verdadeiro entre aplicações distintas ou quando exceder o limite de 5 rótulos.
5. **Como lidar com a compatibilidade de navegadores e considerações de segurança?** O ROR
   é suportado nos principais navegadores a partir do Chrome/Firefox 128+, Safari no macOS
   15+ e [iOS 18](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades)+, com estratégias de
   fallback disponíveis para navegadores mais antigos através de fluxos identifier-first.

### Pontos Principais

Para equipes técnicas e líderes de produto, os pontos essenciais são:

- O ROR permite uma experiência de passkey unificada para uma única aplicação lógica
  distribuída em múltiplos domínios, como aqueles com diferentes TLDs de código de país ou
  marcas alternativas.
- A implementação requer um esforço coordenado: um arquivo `.well-known/webauthn` no lado
  do servidor deve ser publicado no domínio do rpID primário, e todas as aplicações do
  lado do cliente devem ser configuradas para usar esse mesmo rpID compartilhado.
- A decisão de usar o ROR é estratégica. É uma excelente ferramenta para seus casos de uso
  específicos, mas deve ser ponderada em relação a uma arquitetura de login federado mais
  tradicional (OIDC/SAML), especialmente em cenários que envolvem
  [Single Sign-On](https://www.corbado.com/blog/passkeys-single-sign-on-sso) verdadeiro entre aplicações
  díspares.

Recursos como as Solicitações de Origem Relacionada são vitais para o contínuo impulso do
movimento sem senhas. Eles demonstram um compromisso dos órgãos de padronização em abordar
desafios de implementação do mundo real, garantindo que os benefícios das passkeys —
segurança incomparável e experiência de usuário sem esforço — sejam acessíveis até mesmo
para as maiores e mais complexas organizações. À medida que este recurso ganha suporte
universal nos navegadores, ele desempenhará um papel crucial em quebrar as últimas
barreiras para uma internet verdadeiramente global e sem senhas.