Cybersecurity glossary
What is a WebAuthn Relying Party?
Learn what a WebAuthn relying party is, how RP ID and origin binding work, server verification duties, and operational practices for sites that accept passkeys and security keys.
Definition
A WebAuthn relying party (RP) is the web application or service that initiates WebAuthn registration and authentication ceremonies, stores public credentials, and verifies authenticator assertions—identified by an RP ID typically derived from its effective domain.
Why the relying party owns the hard part
Browsers and authenticators make ceremonies smooth. The WebAuthn relying party must still generate challenges, verify cryptography, bind sessions, and govern recovery. Weak RP logic can waste a strong authenticator.
If you deploy passkeys, you are operating as a relying party—even when an IdP hosts the UI.
Relying party responsibilities
Define RP ID and origins
Choose the domain scope credentials will trust and allowlist exact origins.
Drive ceremonies
Build registration and authentication options with fresh challenges.
Verify responses
Check signatures, flags, RP ID hash, origin, and challenge match.
Store public credentials
Persist credential IDs and public keys mapped to user accounts.
Enforce policy
UV requirements, authenticator attachment, attestation rules.
Operate recovery
Backup authenticators and identity-proofed account recovery.
RP ceremony control loop
Create server-side challenge
Store it bound to the user/session with a short TTL.
Return options to the browser
Include RP ID, user info, pubKeyCredParams, and authenticatorSelection.
Receive attestation or assertion
Client posts authenticator output to your verification endpoint.
Validate completely
Use a maintained library to verify all WebAuthn cryptographic steps.
Establish application session
Only after verification succeeds; then invalidate the challenge.
RP ID design pitfalls
| Pitfall | Impact | Fix |
|---|---|---|
| Wrong effective domain | Credentials unusable across intended apps | Plan RP ID before wide enrollment |
| Overly broad related origins | Unexpected sites inherit credentials | Minimize related-origin relationships |
| Skipping origin checks | Phishing resistance broken | Enforce exact expected origins |
| Challenge reuse | Assertion replay | One-time challenges |
Operational checklist
- Treat WebAuthn verification code as security-critical; prefer vetted libraries.
- Document RP ID strategy for production, staging, and regional domains.
- Require user verification for privileged accounts.
- Log registration/authentication outcomes without storing raw authenticator blobs insecurely.
- Support multiple credentials per user and revocation of lost authenticators.
- Align step-up and SSO policies if the IdP is the RP.
- Load-test ceremony endpoints; failed challenges should fail closed.
- Pair passkey success with hardened recovery that does not reintroduce phishable SMS resets carelessly.
The practical takeaway
A WebAuthn relying party is the service that asks for and verifies passkey or security-key proofs. Phishing resistance depends on correct RP ID/origin binding and complete server verification.
Get domain strategy right early, verify every assertion field that matters, and operate credential lifecycle like any other privileged identity control.
Related security terms
Web Authentication API (WebAuthn)
Browser API the relying party uses through the client.
WebAuthn Authenticator
Device that holds keys the RP trusts via public credentials.
WebAuthn Attestation
Optional registration evidence the RP may require.
Identity Provider (IdP)
Often acts as the RP for workforce passkeys protecting SSO.
Passkey
Credential type most RPs are deploying for users.
Frequently asked questions
What is a WebAuthn relying party in simple terms?
It is the website or app that offers passkey login. It asks your device to create or use a key, then checks the cryptographic response before signing you in.
What is an RP ID?
A relying party identifier—usually based on the site’s effective domain (for example example.com)—that scopes where a credential can be used.
Why does RP ID matter for phishing resistance?
Credentials bound to example.com will not produce a valid assertion for evil-example.com, stopping classic lookalike phishing.
Is the IdP or each app the RP?
Either. If users register passkeys at the IdP, the IdP is the RP and apps trust federation. Apps can also be direct RPs for first-party login.
What does the RP store?
Credential ID, public key, sign counter (if used), transports hints, and user handle—not the private key.
What happens if verification is incomplete?
Attackers may replay assertions, abuse wrong origins, or register unexpected authenticators. Server-side checks are mandatory.
Can one company have multiple RP IDs?
Yes across distinct domains. Related subdomains need careful RP ID design; credentials do not automatically work everywhere.
References
Explore authoritative guidance and frameworks related to webauthn relying party.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.