Allow passkey reuse across your sites with Related Origin Requests

Maud Nalpas

Passkeys are tied to a specific website, and they can only be used to sign in on the website they were created for.

This is specified in the relying party ID (RP ID), which for passkeys created for the example.com domain could be www.example.com or example.com.

While RP IDs prevent passkeys from being used as a single credential for authenticating everywhere, they create issues for:

• Sites with multiple domains: Users can't use the same passkey to sign in across different country-specific domains (for example example.com, and example.co.uk) managed by the same company.
• Branded domains: Users can't use the same credential across different domains used by a single brand (for example acme.com and acmerewards.com).
• Mobile apps: Mobile apps often don't have their own domain, making credential management challenging.

There are workarounds based on identity federation, and others based on iframes, but they are inconvenient in some cases. Related Origin Requests offer a solution.

Solution

With Related Origin Requests, a website can specify origins allowed to use its RP ID.

This allows users to reuse the same passkey across multiple sites you operate.

To use Related Origin Requests, you need to serve a special JSON file at a specific URL https://{RP ID}/.well-known/webauthn. If example.com wants to allow the additional origins to use it as an RP ID, it should serve the following file at https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

Next time any of these sites makes a call for passkey creation (navigator.credentials.create) or authentication (navigator.credentials.get) that uses example.com as an RP ID, the browser will notice an RP ID that mismatches the requesting origin. If the browser supports Related Origin Requests, it first looks for a webauthn file at https://{RP ID}/.well-known/webauthn. If the file exists, the browser checks whether the origin making the request is on the allowlist. If yes, it proceeds to passkey creation or authentication steps.

If the browser doesn't support Related Origin Requests, it throws a SecurityError.

Browser support

Set up Related Origin Requests

The following demo uses two sites, https://ror-1.glitch.me and https://ror-2.glitch.me. To enable users to sign in with the same passkey across both of those sites, it uses Related Origin Requests to allow ror-2.glitch.me to use ror-1.glitch.me as its RP ID.

Demo

https://ror-2.glitch.me implements Related Origin Requests to use ror-1.glitch.me as an RP ID, so both ror-1 and ror-2 use ror-1.glitch.me as an RP ID upon creating a passkey or authenticating with it. We've also implemented a shared passkey database across these sites.

Observe the following user experience:

• You can successfully create a passkey, and authenticate with it, on ror-2—even though its RP ID is ror-1 (and not ror-2).
• Once you create a passkey on either ror-1 or ror-2, you can authenticate with it on both ror-1 and ror-2. Because ror-2 specifies ror-1 as an RP ID, making a passkey creation or authentication request from any of these sites is the same as making the request on ror-1. The RP ID is the only thing that ties a request to an origin.
• Once you create a passkey on either ror-1 or ror-2, it can be auto-filled by Chrome on both ror-1 and ror-2.
• A credential created on any of these sites will have an RP ID of ror-1.