WebAuthn RP IDs Turn a Subdomain Decision into an Authentication Boundary
WebAuthn RP IDs Turn a Subdomain Decision into an Authentication Boundary WebAuthn registrations are bound to a relying party identifier, or RP ID. The browser and authenticator use that identifier to decide whether a
WebAuthn RP IDs Turn a Subdomain Decision into an Authentication Boundary
WebAuthn registrations are bound to a relying party identifier, or RP ID. The browser and authenticator use that identifier to decide whether a credential belongs to a site. The default RP ID is the caller's effective domain, according to the Web Authentication specification. A team can choose a broader registrable-domain suffix, which is convenient for a product spread across several subdomains. That convenience also widens the set of origins that can request an authentication ceremony with the same credential family.
The RP ID is not a password and does not leave the authenticator's private key exposed. The important boundary is the relationship between the RP ID, the browser's origin checks, and the server's own verification. The current WebAuthn specification notes that origin validation is an additional layer of protection when an authenticator fails to enforce credential scope. An application that accepts an assertion without checking the expected origin or RP ID weakens that layer.
Subdomain ownership matters because one RP ID can cover many teams and deployment units. If api.example.com, admin.example.com, and customer.example.com all rely on an RP ID of example.com, a security review has to treat the browser-visible trust boundary as the parent domain. A compromised or malicious subdomain may be able to start a ceremony for a credential family that belongs to the parent. The user still has to interact with the authenticator, and the private key is not copied, but the authentication prompt can be induced from an origin the relying party did not intend to trust for that account.
A practical inventory asks three questions. Which origins call navigator.credentials.create() and navigator.credentials.get()? Which RP ID does each call use? Which server-side endpoint validates the origin, RP ID hash, challenge, and credential account? If the answers come from different teams, the design has a governance gap. Put the RP ID into the service catalog with the domains that share it. Treat the parent domain as a trust zone for those credentials.
The server-side verification should reject mismatches explicitly. Check that the client data's type, challenge, and origin match the ceremony that the server started. Check the authenticator data's RP ID hash against the expected value. Bind the challenge to the user session and expire it after a short interval. Do not use a username supplied by the client as the only lookup key. A valid signature over the wrong account or the wrong ceremony is still a failed authentication.
For account recovery, do not create a second path that bypasses the same origin logic. A help-desk reset may be necessary, but it should have its own identity checks, audit trail, and delay for high-value accounts. If a subdomain is compromised, rotate session state and review WebAuthn registrations that were added during the exposure window. Revocation of one credential should be a normal account operation, not a manual database edit.
WebAuthn reduces phishing risk because the authenticator checks the relying party. The application still owns the choice of relying party and the quality of its verification. A parent-domain RP ID should be a deliberate decision with a list of participating origins and a plan for adding or removing a subdomain. A product that treats the RP ID as a convenient default is leaving a security boundary to whoever deploys the next hostname.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.