WebAuthn Related Origins: Cross-Domain Passkey Guide

Passkeys are the new standard for secure, user-friendly authentication. Built on the FIDO/WebAuthn standards, they leverage public-key cryptography to offer inherent resistance to phishing and credential stuffing, dramatically improving security posture while simplifying the login experience for users. For organizations, this translates into tangible business benefits: reduced operational costs from password resets and SMS OTPs, mitigated financial risks from account takeover fraud and increased revenue through higher conversion rates.

However, one of WebAuthn's greatest security strengths - its strict, origin-bound nature - creates a significant real-world challenge for global brands and companies with diverse digital footprints. By design, a passkey created for a specific web domain is cryptographically locked to that domain, a fundamental principle that prevents phishing attacks. While this is a powerful security feature, it leads to a fragmented and confusing user experience when a single brand operates across multiple domains.

A prominent example of this challenge is the rebranding of Twitter to X. A user who created a passkey on twitter.com would find it unusable on x.com, forcing the company to implement cumbersome redirects or require users to re-enroll, creating friction that directly hinders adoption. This is not an isolated issue. Large enterprises like Amazon operate across numerous country-code top-level domains (ccTLDs) such as amazon.com, amazon.de and amazon.co.uk, all sharing a common user account system. In a pre-passkey world, password managers adeptly handle this complexity, but WebAuthn's default behavior would require a separate passkey for each domain, frustrating users and undermining the promise of a seamless login.

To solve this critical adoption blocker, the W3C has introduced a new feature in the WebAuthn standard: Related Origin Requests (ROR). This powerful mechanism provides a standardized, secure way for a set of trusted domains to share a single passkey, creating a unified and seamless authentication experience across a brand's entire digital ecosystem. This deep dive explores the technical foundations of ROR, provides a practical guide to its implementation and analyzes its strategic implications for modern authentication architecture.

The introduction of ROR marks a significant maturation of the WebAuthn standard. The initial specifications prioritized the establishment of core cryptographic and security principles, with the strict binding of a credential to a Relying Party ID (rpID) being a cornerstone of its anti-phishing design. As large-scale enterprise deployments by companies like Amazon and Google became a reality, the practical friction caused by this rigidity became apparent. This friction is a direct impediment to achieving high user adoption, which is the ultimate measure of success for any passkey project. The development of ROR is a direct response to this enterprise feedback, demonstrating a pragmatic evolution of the standard. It acknowledges that for a security protocol to achieve widespread success, its usability must scale to accommodate the complex business realities and branding strategies of the organizations deploying it.

This comprehensive guide answers five critical questions for implementing WebAuthn Related Origin Requests:

1. Why do passkeys fail across multiple domains? Understanding WebAuthn's origin-bound security model and its real-world friction points
2. How do Related Origin Requests technically work? Deep dive into the browser validation flow and .well-known URI mechanism
3. What's required to implement ROR? Step-by-step server and client-side configuration with practical code examples
4. When should you choose ROR over federated login? Strategic decision framework comparing ROR to OIDC/SAML approaches
5. How do you handle browser compatibility and security considerations? Current support matrix and security best practices

For further technical details, see the official WebAuthn Related Origin Requests Explainer.

To fully appreciate the elegance of the Related Origin Requests solution, it is essential to first understand the underlying technical concepts that necessitate its existence: the web's Same-Origin Policy and WebAuthn's Relying Party ID (rpID) scoping rules. These mechanisms are foundational to web security but create the very friction that ROR is designed to alleviate.

A web "origin" is a critical security concept defined by the unique combination of the protocol (e.g., https), domain (e.g., app.example.com) and port (e.g., 443) from which content is served. The Same-Origin Policy is a security mechanism enforced by browsers that restricts how a script loaded from one origin can interact with a resource from another. It is an important element of web security, effectively isolating potentially malicious documents and preventing a fraudulent website from, for example, reading sensitive data from a user's authenticated webmail session in another tab.

In the WebAuthn ecosystem, the "Relying Party" (RP) is the website or application that a user is trying to authenticate with. Every passkey is cryptographically bound to a Relying Party ID (rpID) at the moment of its creation. The rpID is a domain name that defines the scope and boundary for that credential.

By default, the rpID is the effective domain of the origin where the passkey is being created. WebAuthn's scoping rules allow an origin to set an rpID that is either equal to its own domain or a registrable domain suffix. For instance, a script running on https://www.accounts.example.co.uk can create a passkey with an rpID of:

• www.accounts.example.co.uk (the full domain)
• accounts.example.co.uk
• example.co.uk

This flexibility allows a passkey created on one subdomain to be used across other subdomains of the same parent domain, which is a common and necessary pattern. However, the rules strictly prohibit setting an rpID that is not a suffix. The same script on www.accounts.example.co.uk could not create a passkey with an rpID of example.com, because .com is a different top-level domain.

This strict binding serves an important purpose: separating credentials by domain scope. A passkey created for mybank.com cannot be exercised on phishing-site.com because the malicious site cannot claim the legitimate rpID of mybank.com. The browser will not even present the passkey as an option.

However, the rpID itself is not the primary anti-phishing control. WebAuthn's phishing protection actually comes from the origin verification in the clientDataJSON object. During every WebAuthn ceremony, the browser creates a JSON object containing critical context, including the exact origin that initiated the request. This entire object is then cryptographically signed by the authenticator's private key. The server (Relying Party) MUST verify this signature and, crucially, validate that the origin field in the signed clientDataJSON matches an expected, trusted value. This origin verification is what prevents phishing attacks.

With Related Origin Requests, the rpID scoping is relaxed—allowing bar.com to legitimately claim the rpID of foo.com after the browser validates the .well-known/webauthn file—but the origin verification requirement remains unchanged. The clientDataJSON will still truthfully report the origin as bar.com. The server at foo.com receives this signed data, verifies it, and sees that the request came from bar.com. The server must then check that bar.com is an expected related origin before accepting the authentication. This demonstrates a multi-layered approach that allows for greater flexibility without sacrificing the core principle of origin verification.

The Related Origin Requests mechanism introduces an elegant and standardized way for domains to publicly declare a trust relationship for the purpose of sharing passkeys. It leverages a well-established web pattern—the /.well-known/ URI to create a verifiable and machine-readable "allowlist" that browsers can consult.

The core concept is straightforward: a domain that serves as the primary, canonical rpID for a set of related sites can host a special JSON file at a standardized, "well-known" URL: https://{rpID}/.well-known/webauthn. This file acts as a public manifest, explicitly listing all the other origins that are officially authorized to create and use passkeys under that primary rpID.

The browser's validation flow is triggered whenever it encounters a mismatch between the current origin and the requested rpID:

1. A user on a "related" site, such as https://example.co.uk, initiates a passkey operation (creation or authentication) where the client-side code specifies a different domain as the rpID, for instance, example.com.
2. The browser detects this mismatch. Under the old rules, this would immediately result in a SecurityError.
3. With ROR support, the browser, before failing, makes a secure HTTPS GET request to the well-known URL of the claimed rpID: https://example.com/.well-known/webauthn. This request is made without user credentials (like cookies) and without a referrer header to protect user privacy and prevent tracking.
4. The browser receives the JSON response from the server. It parses the file and checks if the current origin (https://example.co.uk) is present in the origins array within the JSON object.
5. If the origin is found in the allowlist, the WebAuthn operation is allowed to proceed using example.com as the valid rpID. If the origin is not found, or if the file is missing or malformed, the operation fails as it would have previously.

The choice to use a /.well-known/ URI is deliberate and aligns ROR with established web standards for service discovery and domain control validation. This URI path, defined by RFC 8615, is already used by numerous critical protocols, including the acme-challenge for Let's Encrypt SSL certificate issuance and assetlinks.json for linking websites to Android applications. By adopting this convention, the W3C leverages a pattern that inherently implies domain ownership. To place a file at this specific, standardized path, one must have administrative control over the web server for that domain. This provides a simple yet effective proof of control, making the declaration of trust verifiable. When the owner of example.com serves a file listing example.co.uk as a related origin, it is a verifiable claim. This web-native approach is far simpler and more robust than alternatives that were considered and rejected during the standardization process, such as using cryptographic keys to sign authorizations (RP Keys) or non-domain-based random identifiers (RP UUIDs). ROR grounds the trust relationship in the existing, well-understood domain control model of the web.

Implementing Related Origin Requests requires coordinated changes on both the server-side, to authorize the origins, and the client-side, to invoke the shared rpID. This section provides the practical code and configuration details needed to enable a unified passkey experience across your domains.

The server hosting the primary rpID is responsible for publishing the allowlist of related origins.

The authorization file must be placed at the exact path /.well-known/webauthn relative to the root of the primary rpID domain. It is critical that this file is served under the following conditions:

• Protocol: It must be served over HTTPS.
• Content-Type: The HTTP response header Content-Type must be set to application/json.
• File Extension: The URL should not include a .json extension. The correct path is /webauthn, not /webauthn.json.

The file must contain a single JSON object with one key, origins, whose value is an array of strings. Each string in the array is the full origin (protocol, domain, and optional port) that is being authorized.

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

Example: For an rpID of example.com, the file must be served at https://example.com/.well-known/webauthn (note: no .json extension).

Once the server is configured with the .well-known/webauthn file, all related domains must consistently use the same shared rpID in their WebAuthn API calls. This coordination is critical for ROR to function correctly.

Key coordination requirements:

1. Backend responsibility: The server generates the cryptographic challenge and specifies the shared rpID in both credential creation and authentication requests
2. Frontend responsibility: All client applications (example.com, example.co.uk, example.de) must pass the same shared rpID to the browser's navigator.credentials API
3. Configuration management: The shared rpID must be treated as a critical global configuration value applied consistently across all related sites

A misconfiguration on even one site—where it defaults to its own origin as the rpID instead of the shared value—will break the unified passkey experience for users on that domain.

Important: The server MUST verify the origin field in the clientDataJSON for every request, ensuring it matches one of the authorized related origins. This origin verification is the primary phishing protection mechanism.

Related Origin Requests (ROR) and federated identity protocols (OIDC/SAML) solve different problems. ROR is not a replacement for Single Sign-On—it's a complement that addresses a specific narrow use case.

ROR is appropriate for a single logical application distributed across multiple related domains that share the same user database:

• Single brand operating multiple country-code TLDs (e.g., amazon.com, amazon.de, amazon.co.uk)
• All domains share the same backend authentication system and user database
• You want to avoid redirect-based flows and keep authentication contextual to each domain
• Your domains fall within the 5-label limit
• Users should experience all domains as one cohesive service

What ROR provides: The same passkey works across all related domains, eliminating the need for users to create separate passkeys for each regional site.

Use federated identity protocols for true Single Sign-On across distinct applications:

• Multiple services with separate user databases or identity systems
• Enterprise scenarios where users need access to many different applications (Salesforce, Office 365, internal tools)
• Third-party application integration
• You need centralized access control, audit trails, and identity governance
• You exceed the 5-label limit for related origins

What OIDC/SAML provides: Centralized authentication where users log in once at an Identity Provider (IdP) and gain access to multiple Service Providers (SPs) through secure tokens.

Important: Passkeys can be used with both approaches. You can implement passkeys at a centralized IdP for federated SSO, or use ROR for a multi-domain single application. Choose based on your architecture, not your authentication method.

While ROR is a powerful technical solution, its implementation should be a deliberate strategic decision. Architects and product managers must weigh its benefits against alternative patterns and understand its limitations to build a robust and future-proof authentication system.

A key constraint of ROR is the "label limit." A "label" in this context refers to the effective top-level domain plus one level (eTLD+1), which is the registrable part of a domain name. For example:

• shopping.com, shopping.co.uk, and shopping.ca all share the single label "shopping"
• myshoppingrewards.com introduces a new, distinct label: "myshoppingrewards"
• travel.shopping.com still falls under the "shopping" label

The WebAuthn Level 3 specification requires browser implementations to support a minimum of five unique labels in the origins list. As of 2025, no known browsers support more than this minimum of five labels. Therefore, organizations should design their ROR deployments with this hard limit in mind—treat five as the effective maximum.

This limit is a deliberate anti-abuse mechanism designed to prevent misuse. It stops entities like shared hosting providers (e.g., wordpress.com) from creating a universal passkey that could work across thousands of unrelated customer subdomains, which would undermine the security model.

For most organizations, even large multinational brands, this five-label limit is sufficient. For example, Amazon's various country-code TLDs (amazon.com, amazon.de, amazon.co.uk, etc.) all share the "amazon" label, leaving four additional label slots available for other brands in their portfolio like "audible" or "zappos."

The complexity of implementing ROR depends heavily on whether it is being introduced into a new system or retrofitted onto an existing one.

• Greenfield Deployments: For new projects, the strategy is straightforward. A single, canonical domain should be chosen as the shared rpID from the outset (e.g., the primary .com domain). This rpID should then be used consistently in the configuration of all related websites and applications from day one.
• Existing Deployments: Retrofitting ROR onto a system that already has passkeys deployed with different rpIDs across its domains is significantly more complex. A direct migration is not possible, as existing passkeys are permanently bound to their original rpIDs. The recommended approach in this scenario is to implement an "identifier-first" login flow. The user is first prompted to enter their username or email. The backend then performs a lookup to determine which rpID their existing passkey is associated with. Finally, the user is redirected to the correct origin corresponding to that rpID to complete the authentication ceremony. After a successful login, they can be redirected back to their original site. This is a considerable architectural undertaking that requires careful planning and implementation.

Understanding how established companies implement Related Origin Requests provides valuable insights for your own deployment strategy. Below are examples based on actual implementations (as of October 2025):

Microsoft uses ROR for their authentication infrastructure. The actual configuration at login.microsoftonline.com includes:

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

This conservative approach enables passkey sharing between Microsoft's enterprise and consumer login portals while maintaining a focused security perimeter.

Shopify implements ROR to unify authentication across select domains:

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

This configuration allows Shopify to connect their main platform with their Shop app, demonstrating a focused approach to related origins.

Amazon has a rather large file:

// 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"
  ]
}

This pattern would allow a brand to provide unified passkey authentication across regional domains while using the primary .com domain as the rpID.

These real-world examples reveal several key patterns:

1. Primary Domain as rpID: All companies use their primary .com domain as the canonical rpID
2. Logical Grouping: Origins are grouped by business function rather than technical architecture
3. Conservative Scope: Most implementations stay well under the 5-label limit, typically using 3-4 origins
4. Subdomain Strategy: Many use subdomains of the primary domain to maintain brand consistency

As a modern web standard, ROR has been designed with security as a primary consideration and is seeing active adoption across major browsers.

Related Origin Requests do not compromise WebAuthn's core anti-phishing guarantees. The mechanism is carefully designed to maintain a strong security posture:

• Origin Verification: As discussed, the browser still includes the true origin of the request in the signed clientDataJSON. The Relying Party server MUST verify this origin to ensure the request is coming from an expected source, preventing a compromised related origin from impersonating another.
• Secure Fetch: The browser's request to the .well-known/webauthn file is made over HTTPS. Furthermore, the specification mandates that this fetch be performed without credentials (e.g., cookies) and without a Referer header. This prevents the request from being used to leak user information or for cross-site tracking purposes.
• Server Security: The .well-known/webauthn file itself becomes a critical security asset. An attacker who gains control of the web server hosting the primary rpID could potentially modify this file to add their own malicious domain to the allowlist. Therefore, securing the infrastructure that serves this file is of paramount importance.

Related Origin Requests is a feature of the WebAuthn Level 3 specification. Browser support began rolling out in late 2024:

Key facts:

• Chrome and Edge: Added ROR support in version 128 (August 2024)
• Safari: Added ROR support in Safari 18, available on macOS 15 and iOS 18 (September 2024)
• Firefox: No current support for ROR; feature-detect and implement fallback flows

For applications needing to support older browsers or Firefox, implement a fallback strategy:

1. Feature detection: Check for ROR support using PublicKeyCredential.getClientCapabilities()
2. Identifier-first flow: Prompt for username/email, lookup the user's associated rpID, then redirect to the appropriate origin for authentication
3. Graceful degradation: Allow users to create separate passkeys per domain if ROR is unavailable

Data based on current support matrices as of October 2025.

Implementing Related Origin Requests requires careful coordination between multiple technical teams and deep expertise in WebAuthn protocols. Corbado's passkey adoption platform eliminates this complexity by providing enterprise-ready solutions for multi-domain passkey deployments.

Corbado handles the technical complexity of Related Origin Requests through:

• Automated Configuration: Our platform automatically generates and hosts the required .well-known/webauthn files with proper security headers and JSON formatting
• Multi-Domain Dashboard: Centralized management interface for configuring related origins across your entire domain portfolio
• Validation Tools: Built-in testing and validation to ensure your ROR configuration works correctly across all browsers and platforms

Beyond technical implementation, Corbado provides the security framework enterprises need:

• Origin Verification: Automatic validation of clientDataJSON origins to prevent related domain abuse
• Audit Logging: Comprehensive tracking of passkey usage across all related domains for compliance and security monitoring
• Incident Response: Real-time alerts and automated responses for suspicious cross-domain authentication attempts

For organizations with existing passkey deployments, Corbado offers:

• Legacy Migration Tools: Automated analysis of existing rpID configurations and migration path recommendations
• Identifier-First Flows: Pre-built login components that handle complex multi-rpID scenarios during transition periods
• API Integration: RESTful APIs and SDKs that integrate seamlessly with your existing authentication infrastructure

Ready to implement Related Origin Requests for your organization? Corbado's expert team can help you design and deploy a unified passkey experience across your entire digital ecosystem. Contact our solutions team to discuss your specific requirements and timeline.

The promise of passkeys lies in their ability to deliver a future that is both more secure and remarkably simpler for users. However, for this future to become a reality at a global scale, the standard must accommodate the architectural complexities of modern digital brands. The friction created by strictly domain-bound passkeys has been a significant blocker to adoption for organizations with multi-faceted online presences.

WebAuthn Related Origin Requests provides the standardized, secure, and elegant solution to this problem. By allowing a single passkey to work seamlessly across a trusted set of related domains, ROR eliminates a major point of user confusion and frustration.

This guide addressed five critical questions for implementing WebAuthn Related Origin Requests:

1. Why do passkeys fail across multiple domains? WebAuthn's origin-bound security model cryptographically locks passkeys to specific domains to prevent phishing, but this creates friction when brands operate across multiple domains like different country TLDs.
2. How do Related Origin Requests technically work? ROR uses a standardized .well-known/webauthn file to create a verifiable allowlist of related domains, enabling browsers to validate cross-domain passkey usage through a secure HTTPS fetch process.
3. What's required to implement ROR? Implementation requires server-side configuration of the .well-known/webauthn manifest file and client-side coordination to use a shared rpID consistently across all related origins.
4. When should you choose ROR over federated login? Use ROR for unified brand experiences across related domains with shared user databases; use OIDC/SAML for true SSO across distinct applications or when exceeding the 5-label limit.
5. How do you handle browser compatibility and security considerations? ROR is supported in major browsers from Chrome/Firefox 128+, Safari on macOS 15+, and iOS 18+, with fallback strategies available for older browsers through identifier-first flows.

For technical teams and product leaders, the essential points are:

• ROR enables a unified passkey experience for a single logical application spread across multiple domains, such as those with different country-code TLDs or alternate branding.
• Implementation requires a coordinated effort: a server-side .well-known/webauthn file must be published on the primary rpID's domain, and all client-side applications must be configured to use that same shared rpID.
• The decision to use ROR is a strategic one. It is an excellent tool for its specific use cases but should be weighed against a more traditional federated login architecture (OIDC/SAML), especially in scenarios involving true Single Sign-On across disparate applications.

Features like Related Origin Requests are vital for the continued momentum of the passwordless movement. They demonstrate a commitment from the standards bodies to address real-world implementation challenges, ensuring that the benefits of passkeys—unparalleled security and effortless user experience—are accessible to even the largest and most complex organizations. As this feature gains universal browser support, it will play a crucial role in breaking down the final barriers to a truly global, passwordless internet.