Developers implementing Okta passkeys across multiple domains or complex brand structures encounter authentication scoping limitations because the Web Authentication (WebAuthn) specification scopes passkeys to the Relying Party Identifier (RP ID) used during creation. To resolve this limitation and extend passkeys across distinct domains, administrators must configure subdomain sharing, same-party federation, or related origin requests. When a user creates a passkey with an RP ID, it remains valid on that RP ID and any subdomains, but it does not automatically extend to sibling domains, cousin subdomains, or entirely different top-level domains.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Passkeys
• Web Authentication (WebAuthn)
• Custom Domains

The Relying Party Identifier (RP ID) serves as the core mechanism for passkey scoping. Per the Web Authentication (WebAuthn) specification, a passkey functions on an origin if the RP ID equals, or acts as a registrable domain suffix of, the effective domain of that origin. In practice, this means a passkey that a user registers with an RP ID of <login.example.com> functions on any subdomain of <login.example.com> (for example, <app1.login.example.com>) because those origins have <login.example.com> as a domain suffix. It does not function on <example.com> itself, on sibling subdomains like <other.example.com>, or on unrelated domains and top-level domains (TLDs) (for example, <example.ca>) because the suffix relationship only flows downward from the RP ID. This foundational security feature prevents cross-site credential sharing, but it becomes a limitation when an organization needs a single passkey to span genuinely distinct domains, brand TLDs, or acquired properties.

How does an administrator configure passkeys for multiple domains?

Configure passkeys to support multiple domains by implementing subdomain sharing, same-party federation, or related origin requests based on the security requirements and brand architecture of the environment.

• Option 1: Subdomain Sharing (The Root Domain Approach)
  • Set the RP ID to the root domain (e.g., <example.com>).
  • This allows a single passkey to function across all subdomains of that root (e.g., <a.example.com> and <b.example.com>), since they all have <example.com> as a valid registrable domain suffix.
  • Trade-off: All passkeys that a user generates for that root domain display to the user on every participating subdomain. If many distinct brands share the root domain, this causes user experience clutter in the passkey manager.
• Option 2: Same-Party Federation (Recommended)
  • Centralize login on a single Identity Provider (IdP) domain (e.g., <login.brand.com>) instead of attempting to share one passkey across multiple domains.
  • Users create and authenticate the passkey only on <login.brand.com>.
  • Other applications (e.g., <brand.ca> or <brand-shopping.io>) do not interact with WebAuthn directly. Since these domains do not share a common root with <login.brand.com>, they cannot reuse the passkey via Option 1. Instead, they redirect the user to <login.brand.com> using OpenID Connect (OIDC) or Security Assertion Markup Language (SAML), and receive a token confirming the identity of the user.
  • Okta handles the passkey ceremony at the federation layer instead of the browser layer since only one domain performs the authentication.
  • This provides the most robust and platform-agnostic option, and it proves especially valuable when applications live on domains that do not share a suffix at all (different TLDs, acquired brands, etc.).
• Option 3: Related Origin Requests
  • Utilize Related Origin Requests (ROR) if federation proves unfeasible, such as during corporate acquisitions or when utilizing Country Code Top-Level Domains (e.g., <.ca> and <.uk>).
  • Host a .well-known/webauthn file on the primary RP ID domain that explicitly lists the other allowed origins.
  • Limitations:
    • The WebAuthn specification requires clients to support a minimum of five unique registrable-domain labels in the origins list. Treat five as the safe design ceiling for planning purposes, since it represents the only number guaranteed by the specification, even though some browsers allow more in practice.
    • Real-world enforcement varies by browser and version. Testing shows Chromium-based browsers accept well beyond five labels, while Safari fails once an entry appears past roughly the fifth position. Firefox did not support ROR at all until a 2026 release. Because this behavior depends on the version and vendor, always verify current support against the target browser matrix rather than relying on a fixed number.
    • Administrators must implement a fallback authentication mechanism (e.g., identifier-first login with backend RP ID lookup) for browsers that do not support ROR or that throw a SecurityError when the related-origins check fails.

Administrators must follow implementation best practices for passkeys

Review the following best practices to ensure a secure and reliable passkey implementation across multiple domains.

• Explicitly set the RP ID: Never allow the browser to infer the RP ID. Explicitly define it in the create() and get() calls to ensure it perfectly matches the backend verification logic.
• Permanent scoping: Once a user creates a passkey, the RP ID cannot change. If administrators roll out passkeys with a narrow RP ID and the architecture later expands to multiple domains, users must re-enroll unless the new RP ID acts as a parent domain that the old RP ID falls under (Option 1), or Related Origin Requests bridge the two (Option 3).
• Custom domains: Always use a dedicated custom domain as the RP ID. Avoid using vendor-owned domains to prevent credentials from different organizations from overlapping in the passkey manager of the end-user.
• Verify browser support before relying on ROR: Because Related Origin Requests support and label-limit enforcement differ across browsers and change over time, confirm current behavior for Chrome, Edge, Safari, and Firefox in the target environments, and always ship a fallback flow.

Related References

• Passkeys.dev Related Origins Tool
• Customize the Passkeys (FIDO2 WebAuthn) relying party ID domain