WebAuthn RP ID Scopes Credential Use

A WebAuthn credential is not a reusable key that any website can request from an authenticator. Registration and authentication are tied to a relying party identifier, or RP ID, while the browser also evaluates the calling origin. That pairing creates a domain boundary around public-key credentials.

For a conventional deployment at https://login.example.com, an RP can use the host itself as the RP ID:

origin: https://login.example.com
RP ID:  login.example.com

It can also use a registrable domain suffix such as example.com when the deployment needs credentials to serve eligible subdomains:

origin: https://login.example.com
RP ID:  example.com

The browser validates this relationship before passing a WebAuthn operation to the authenticator.

RP ID is part of credential identity

During credential creation, the authenticator associates the credential with an RP ID. WebAuthn represents that binding in the RP ID hash stored with authenticator data.

For an authentication ceremony, the authenticator receives the RP ID selected for the request and produces authenticator data containing its SHA-256 hash. The server verifies that field against the RP ID it expects.

rpIdHash = SHA-256(RP ID)

This check matters because a valid signature alone does not establish that the assertion belongs to the intended relying party. Server verification combines the signature with ceremony context, including the expected challenge, origin, RP ID hash, and other required fields.

The browser constrains RP ID selection

A page cannot choose an arbitrary unrelated domain as its RP ID. WebAuthn requires the effective domain of the caller to be equal to, or a registrable-domain suffix of, the RP ID relationship allowed by the specification.

A page on login.example.com can commonly use login.example.com or example.com. It cannot claim bank.example.net merely by placing that value in a WebAuthn request.

login.example.com -> login.example.com   valid scope
login.example.com -> example.com         parent-domain scope
login.example.com -> example.net         rejected

This browser-side validation prevents a hostile site from directly asking an authenticator to operate on credentials scoped to an unrelated relying party.

Origin and RP ID are separate checks

RP ID and origin are related, but they are not interchangeable. The RP ID defines the credential scope used by the authenticator. The origin identifies the web security origin that initiated the ceremony and is carried in clientDataJSON.

A server should compare the returned origin with the origin or origin set that it explicitly permits. It should also verify that rpIdHash matches the configured RP ID.

clientDataJSON.origin -> expected origin
authenticatorData.rpIdHash -> SHA-256(expected RP ID)

Checking only one side leaves part of the ceremony context unverified.

Parent-domain scope expands the trust boundary

Choosing example.com as the RP ID can support authentication from multiple eligible subdomains. That can be useful for a deliberately shared sign-in architecture, but it also broadens the domain boundary compared with login.example.com.

The choice should follow the deployment model rather than convenience. If only one host performs authentication, a host-specific RP ID keeps the credential scope narrow. If several subdomains must share the same credential scope, the parent-domain choice should be treated as an explicit security boundary.

Domain ownership alone does not make every application beneath that domain equally trusted. Subdomain lifecycle, delegated hosting, and application isolation remain relevant when a parent-domain RP ID is selected.

Challenges still bind individual ceremonies

RP ID scoping does not replace the challenge. The server creates a fresh challenge for a registration or authentication ceremony and later verifies that the returned clientDataJSON contains the expected value.

The challenge binds a response to a server-initiated ceremony. The RP ID limits the relying-party scope of the credential. Origin verification identifies the calling web origin. These controls cover different parts of the protocol and should not be collapsed into a single check.

A server also validates the ceremony type, such as webauthn.create or webauthn.get, along with the remaining fields required by its WebAuthn verification procedure.

Configuration must stay consistent across registration and sign-in

Changing the RP ID after credentials have been created can make those credentials unavailable for later authentication under the new scope. A migration from a host-specific RP ID to a parent-domain RP ID is therefore not equivalent to changing a display label.

Registration and authentication endpoints should derive their expected RP ID from stable configuration. Reverse proxies and application frameworks can influence the apparent request host, but server verification should not silently turn arbitrary incoming host data into the trusted RP ID.

The same discipline applies to origin allowlists. A deployment with several legitimate origins should enumerate the accepted set according to its architecture rather than accept any origin that merely resembles the request host.

Verification belongs on the server boundary

Browsers enforce important preconditions before invoking WebAuthn, but the relying party still has a verification job. For authentication, that includes checking the challenge, origin, RP ID hash, signature, and applicable authenticator data and credential state.

RP ID scoping is strongest when it is treated as a fixed part of the relying party’s security model. A narrow scope limits where a credential can participate, while explicit server checks ensure that a signed assertion is accepted only in the ceremony context for which it was issued.

References

Cybersecurity WebAuthn Authentication Passkeys