Coming soon to Chrome and Safari: WebAuthn related origins

If you set up a WebAuthn credential on Twitter before its application moved to x.com, you may notice when authenticating that it redirects to twitter.com in order to prompt the browser to authenticate with a credential registered to twitter.com. Without redirecting to twitter.com, the browser would only allow the relying party ID to be x.com, which would make previously established credentials useless.

The WebAuthn specification is being updated to offer related origins, which will permit a page on another origin to specify a relying party ID that is naturally bound to another origin. By implementing the related origins draft specification, twitter.com could host a .well-known/webauthn response which gives x.com permission to use twitter.com as a relying party ID.

Why bind origins and relying party IDs together?

Tools like EvilProxy give threat actors an easy way to present an identical experience to the user without appearing different from the real site. While password managers will notice the origin is different, users may manually enter their credential information and TOTP or SMS OTP codes. Users cannot, however, use a WebAuthn credential or passkey on a phishing origin. This makes WebAuthn credentials and passkeys a robust alternative to One-Time-Passwords as a phishing-resistant second factor.

To mitigate phishing, browsers require the relying party ID, which is communicated to the authenticator, to match the origin — or a parent top level origin — of the page using the credential API. This protects against man-in-the-middle origins like EvilProxy.

A thorn to the user experience

This constraint affects large brands like Amazon, who recently announced passkey support. Amazon's implementation will leave some customers with multiple credentials for the same account on Amazon, as Amazon operates across multiple top level domains like .com and .de. Experiences like this make it harder for users to switch to passwordless authentication over the lifetime of their engagement with services like Amazon.

amazon.com and amazon.de have separate passkeys
Two passkeys for Two Relying Party IDs on the Same Device (Windows 11 + Chrome 118) from Amazon Passkeys: Response to Consumer Demand with Poor Implementation.

Similarly, this constraint requires workarounds to redirect users across origins during authentication, which can be confusing or concerning to the security-minded user.

On January 23, 2024, X announced they are adding passkey support for iOS. While this makes it easier to authenticate in the app, the synced passkey cannot be used in a one-touch experience on the web, as the relying party ID is set to x.com.

X.com will be able to use passkeys tied to twitter.com after implementing the /.well-known/webauthn endpoint on twitter.com with supported browsers.

When a supported browser sees a relying party ID which does not match the origin of the requesting web page, it can request the well-known endpoint to see if the current page is authorized to use that relying party ID.

GET /.well-known/webauthn
Host: twitter.com

Content-Type: application/json
Content-Length: 81

{
    "origins": [
        "https://twitter.com",
        "https://x.com"
    ]
}

Should that page be authorized, then the browser will present the relying party ID as usual to authenticators. No redirect or iframe to the original domain will be required to securely authenticate with WebAuthn.

A catch is that the origin and all other related origins will have to commit to using the same relying party ID for the lifetime of all existing credentials, which may be forever. In other words, X will have to continue supporting twitter.com as a relying party ID for the lifetime of the service and all of its customers identities.

For large brands like Amazon and X (formerly Twitter), this is a misicule price to pay for a better user experience across domains.

Limitations in the specification

Clients are expected to support at least five related origin labels. A label happens to be the origin without a public suffix, such as .com or .co.uk. While the list must include all eligible origins verbatim, the list is limited in how many different names can be included.

For example, this limit is more likely to impact Microsoft than Amazon, as they have a variety of properties like live.com, xbox.com, azure.microsoft.com, login.microsoftonline.com, and so on where "live", "xbox", and "azure.microsoft", "login.microsoftonline" are distinct labels. While Microsoft is likely to exceed the label limit, they also have separate user pools.

Amazon is more consistent with their domain names. I found 176 CC TLDs registered with "amazon", 17 of them are in use, 88 of them redirect, and the rest are unusable or unrelated to Amazon, Inc. There are likely more that I missed, such as .co.{cc} and .com.{cc}. In Amazon's case, their .well-known/webauthn response would be larger than most, but still fit within the label constraint currently specified.

Browsers may also constrain the maximum size of the response. Should Amazon send 128 KB of JSON to the browser when it queries the .well-known/webauthn endpoint, the browser may discard the entire response.

These limits stop a shared hosting provider, like wordpress.com, from offering passkeys across all domains hosted on their infrastructure. It would also be improper to serve a response that identifies all properties that WordPress hosts. That said, all WordPress hosted blogs redirect to https://wordpress.com/log-in to authenticate.

Following the release of Mobile Safari in iOS 18 beta 3 and Safari in macOS 15 beta 3, Chrome Canary >= 128.0.6591.0 now also supports related origins
Adam Langley - Fri, 12 Jul 2024 - webauthn adoption mailing list

We should expect Chrome to support related origins outside of Canary in a few months, and Safari on macOS and iOS to support it later this year when macOS 15 is released. Edge, and other Chrome derivitives should follow shortly. As for Firefox, they are still implementing WebAuthn level 3, such as the PRF Extension, and I cannot find any comment or bug related to related origins in their tracker.

Footnotes

  1. Time-based One-Time-Password
  2. Please do not use SMS One-Time-Passwords except to verify ownership of the phone number when associating a number to a user. Phone numbers can be swapped to other devices without the true owner knowing. This is called SIM swapping.
  3. Passkeys are a discoverable WebAuthn credential that includes a user identifier in the WebAuthn response. This allows a website to authenticate a user without requiring them to enter a username and password, while mitigating several weaknesses like reused passwords and phishing.
  4. Unless the phishing origin is a subdomain related to the top level origin! This may happen through Subdomain takeover or a breach of the nameserver configuration hosting the domain. For example, if the attacker has control of a related origin such as dev.example.com, they can request a credential for example.com without the browser's protection engaging. Although, dev.example.com cannot request a credential for auth.example.com, as they are siblings in the domain hierarchy.
  5. Coming soon! See When will related origins arrive?
  6. Clients or browsers may also choose not to take more than five labels.
  7. This term appears tied to Amazon Cognito. It might also be called a realm. In either case, it is a set of identities and associated credentials which are held and authenticated separately across different products, services, and experiences.