Verify topOrigin during credential registration and authentication

[nicolastemciuc]

Note

This is a Level 3 feature based on the latest W3C Working Draft

Summary

This PR introduces support for verifying the top_origin parameter reported by the browser during WebAuthn registration and authentication ceremonies.

The topOrigin value identifies the top-level origin under which a WebAuthn ceremony is taking place, typically relevant when credentials are created or used within iframes or embedded contexts.

To support this, a new configuration option is added:

config.allowed_top_origins = ["https://app.example.com"]

If the top_origin reported by the browser is not included in allowed_top_origins, the operation will be rejected.

References

• 7.1. Registering a New Credential
• 7.2. Verifying an Authentication Assertion
• 13.4.9. Validating the origin of a credential

Related blogs

• Passkeys & iframes
• Cross Origin Credential Creation

[nicolastemciuc]

The WebAuthn specification provides several examples of how the top origin can be validated:

Similar considerations apply when validating the topOrigin member of the client data. When topOrigin is present, the Relying Party MUST validate that its value is expected. This validation MAY be performed by exact string matching or any other method as needed by the Relying Party. For example:

• A web application that does not wish to be embedded in a cross-origin iframe might require topOrigin to exactly equal origin.
• A web application that wishes to be embedded in a cross-origin iframe on a small number of domains might require topOrigin to exactly equal some element of a list of allowed origins, for example the list ["https://example-partner1.org", "https://login.partner2-example.org"].
• A web application that wishes to be embedded in a cross-origin iframe on a large number of domains might allow any value of topOrigin, or use a dynamic procedure to determine whether a given topOrigin value is allowed for a particular ceremony.

This PR doesn't yet allow configuring the allowed top origin dynamically or with unrestricted values. If we want to support those cases, we can address them in a follow-up PR.

[santiagorodriguez96]

Nice job!

Leave a couple of thoughts to discuss, but is looking good overall. Perhaps we have to test this with our demos to ensure is working correctly in a real life scenario 👀

[nicolastemciuc]

Perhaps we have to test this with our demos to ensure is working correctly in a real life scenario

After testing locally with two demos, I discovered that we were incorrectly expecting crossOrigin to be a string instead of a boolean. I fixed this in 08f2b25.