Relying Party (RP)
The application that relies on an external identity provider to authenticate users. The term is used in OIDC and WebAuthn. The RP validates tokens or assertions but does not store user credentials itself.
Being a relying party means outsourcing authentication and keeping responsibility for validation, which is where the bugs live: accepting an assertion without checking the audience, trusting a signature algorithm the attacker chose, or treating an ID token as an API credential. In WebAuthn the RP identifier is also the security boundary, since it determines which origin a credential will sign for.
See also: identity provider, OpenID Connect, WebAuthn and FIDO2, validate a JWT recipe
Related on Start with Identity
- GlossarySSO
Single Sign-On. A user authenticates once and gains access to multiple applications without re-entering credentials. Implemented with SAML or OIDC in modern dep
- GlossaryClaims
Statements about a subject carried in a token, such as subject identifier, email, roles, or expiry. Relying parties make authorization decisions from claims, so
- GlossaryID Token
A JWT issued by an OpenID Connect provider that conveys authentication claims about the user. Unlike access tokens, ID tokens are intended for the client, not f
- CVEDrupal Simple OAuth/OIDC auth bypass via an alternate path
Drupal Simple OAuth / OIDC 6.0.0 through 6.0.6 allowed authentication to be skipped on an alternate path. Patched in 6.0.7.
- CVEKeycloak session hijack via prompt=login re-authentication
Starting a new authentication with prompt=login could hijack an existing Keycloak session. The re-auth step did not bind to the original user tightly enough. Pa
- CVEOpenID private_key_jwt audience ambiguity
The OpenID Connect twin of CVE-2025-27371. private_key_jwt audience is ambiguous at the spec layer, so a client assertion can be replayed across authorization s