RPOrigin is validated exactly against the url's fully qualified host name leaving no room for other use cases. about webauthn HOT 5 CLOSED

I got the same issue too

from webauthn.

Would it be possible for you to set your RPID to domain.com when initating the flow on auth.domain.com ? then sub.domain.com will be able to verify the assertion just fine as sub.domain.com is a valid origin for the domain.com rpId

By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain. This default MAY be overridden by the caller, as long as the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin's effective domain.

Note: An RP ID is based on a host's domain name. It does not itself include a scheme or port, as an origin does. The RP ID of a public key credential determines its scope. I.e., it determines the set of origins on which the public key credential may be exercised, as follows:
The RP ID must be equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain.
The origin's scheme must be https.
The origin's port is unrestricted.
For example, given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: login.example.com (default) and example.com, but not m.login.example.com and not com.

This is done in order to match the behavior of pervasively deployed ambient credentials (e.g., cookies, [RFC6265]). Please note that this is a greater relaxation of "same-origin" restrictions than what document.domain's setter provides.

These restrictions on origin values apply to WebAuthn Clients.

Basically if you set the rpId manually in your navigator.credentials.get call like this :

{ rp : { id : "domain.com" }}

Then the clientDataOrigin will report domain.com instead of auth.domain.com

If you then set relyingPartyOrigin to domain.com too the check will succeed.

from webauthn.

webauthn-rs also takes a list of origins. So it might be indeed the more ergonomic API to adapt:

kanidm/webauthn-rs#193

from webauthn.

Support for multiple origins is also in the two libraries I wrote:

• MasterKale/SimpleWebAuthn#91
• https://github.com/duo-labs/py_webauthn/blob/master/webauthn/authentication/verify_authentication_response.py#L48

It's a common enough scenario in more complex RPs that I think this library should implement similar functionality.

from webauthn.

yeah scoping roprigin to a general domain would work for some use cases. I was also looking into supporting the list of unrelated domains.

from webauthn.