Category: Federation & SSO

Relying Party

Also known as: RP, Relying Party (RP)

Simply put

A relying party is an application or service that depends on an external authority to verify who a user is before granting access to a protected resource. Rather than checking credentials itself, it trusts and consumes assertions or tokens issued by that authority. In this way it relies on someone else's identity verification to make its own access decisions.

Formal definition

A Relying Party (RP) is an entity that controls access to a protected resource and depends on the validity of security tokens or assertions issued by a trusted authority (such as an identity provider or, in some standards, a credential service provider) to authenticate the entities requesting access. In federation deployments the RP typically consumes tokens or assertions to establish an authenticated session; note that the term is used with slightly different framing across standards. In NIST SP 800-63-3 the RP relies on a subscriber's authenticated identity and the associated assertions from an identity provider, and is described as depending on the validity of the digital signature or authentication process. The RP performs authorization for its own resources based on the authenticated identity, but the underlying identification and authentication are typically delegated to the trusted authority. Exact responsibilities, token validation, assertion verification, trust establishment, and session handling, depend on the applicable protocol and profile (for example OIDC, where the RP is the OAuth 2.0 client, or SAML 2.0, where the analogous role is the service provider). RPs are noted as valuable targets for attackers seeking to impersonate valid subscribers or obtain information about them, per NIST guidance.

Why it matters

The relying party is where delegated identity actually turns into access. Because the RP does not verify credentials itself but instead trusts assertions or tokens issued by an external authority, the security of everything it protects hinges on how carefully it validates what it receives. A relying party that accepts a poorly validated token, ignores signature checking, or fails to confirm the intended audience effectively outsources its front door to whoever can forge or replay an assertion. In federated architectures this concentration of trust is deliberate and efficient, but it also means the RP inherits the consequences of any weakness in the trust relationship.

Relying parties are, per NIST guidance, a valuable target for attackers seeking to impersonate valid subscribers or obtain information about them. This makes correct token and assertion handling at the RP a first-order security concern rather than an integration detail. The RP must establish and maintain a well-defined trust relationship with its identity provider or credential service provider, and it must treat token validation, checking signatures, issuer, audience, and expiry, depending on the applicable protocol and profile, as a required control rather than an optional convenience.

Understanding the RP role also clarifies a division of responsibility that is easy to blur. Identification and authentication are typically delegated to the trusted authority, while the RP performs authorization for its own resources based on the authenticated identity it is handed. Teams that misplace this boundary, expecting the identity provider to enforce fine-grained access, or expecting the RP to re-authenticate users it should trust, tend to build systems that are either over-permissive or unnecessarily brittle.

Who it's relevant to

Security Architects

Architects define the trust relationships between relying parties and their identity providers or credential service providers, and decide which protocol and profile (for example OIDC or SAML 2.0) governs each integration. They must design for the RP as a high-value attack target and ensure that token and assertion validation is a mandatory control across every consuming application.

IAM and Federation Engineers

Engineers implement the RP side of federation flows, configuring the OAuth 2.0 client in OIDC or the service provider in SAML 2.0, wiring up token or assertion consumption, and handling session establishment. Correct signature, issuer, audience, and expiry checks, as applicable to the profile in use, fall squarely on their work.

Compliance and Assurance Leads

Because NIST SP 800-63-3 frames the RP as depending on the validity of the identity provider's assertions and digital signatures, compliance leads mapping deployments against that guidance need to confirm that relying parties correctly rely on authenticated identities and validate what they consume, rather than performing ad hoc credential checks.

System Administrators

Administrators operate and maintain the applications acting as relying parties, including managing the trust configuration, certificates or keys used for validation, and session behavior. Because the RP guards access to protected resources and is an attractive target, keeping its trust relationships and validation settings current is an ongoing operational responsibility.

Inside RP

Client/RP Identifier

A unique identifier registered with the identity provider (in OIDC, the client_id) that the RP presents when initiating authentication or token requests. In SAML 2.0 federation the equivalent is the service provider's entity ID.

Redirect/Reply Endpoints

The registered URIs (OIDC redirect_uri or SAML Assertion Consumer Service URL) to which the identity provider returns authentication responses. Strict matching of these endpoints is typically required to prevent response interception.

Token/Assertion Validation Logic

The RP-side processing that consumes and verifies the identity provider's output: validating a SAML 2.0 assertion or, in OpenID Connect, the ID token. Validation typically includes checking the signature, issuer, audience, and expiry claims.

Trust Configuration

The metadata and keys establishing trust in the identity provider, such as the IdP's signing keys or certificates and, in OIDC, discovery/JWKS information used to verify the signature on an ID token.

Consumed Identity Claims

The subject identifier and attribute claims the RP receives about the authenticated principal, delivered via a SAML 2.0 assertion or an OIDC ID token, which the RP uses to establish a local session or map to an account.

Common questions

Answers to the questions practitioners most commonly ask about RP.

Is a Relying Party the same thing as the identity provider that authenticates the user?

No. A Relying Party is the application or service that consumes and relies on assertions or tokens issued by an external authority; the identity provider (IdP) or OpenID Provider is the party that actually performs authentication and issues those assertions or tokens. The RP delegates the authentication step to the provider and then makes access decisions based on the result. Conflating the two roles is a common source of confusion, since the RP verifies the assertion or token it receives but does not itself directly authenticate the user's credentials in most federated deployments.

Does being a Relying Party mean the application handles authorization for the user?

Not inherently. The RP role concerns receiving and trusting the outcome of a federated authentication (or, in OAuth 2.0 delegated authorization contexts, receiving tokens on behalf of a resource). Authentication establishes who the principal is; authorization determines what that principal may do, and that is typically a separate step the RP or a downstream policy decision point performs after identity is established. An RP may consume identity information and then apply its own authorization logic, but the two functions remain distinct and should not be treated as a single operation.

How does the terminology for a Relying Party differ across SAML, OpenID Connect, and OAuth 2.0?

The concept appears under different names depending on the standard. In SAML 2.0, the RP corresponds to the Service Provider (SP) that consumes assertions from an Identity Provider. In OpenID Connect, the term Relying Party is used explicitly for the client application that relies on the OpenID Provider for authentication. In OAuth 2.0, the analogous actor is generally called the client, though OAuth 2.0 is a delegated authorization framework rather than an authentication protocol. When documenting an integration, it is generally advisable to state which standard and profile you mean so the role is unambiguous.

What does an RP typically need to validate when it receives a token or assertion?

Validation requirements depend on the protocol and profile, but typically an RP checks the signature against the issuer's published keys, confirms the issuer and audience match expected values, verifies the token or assertion has not expired and is within any acceptable time window, and checks for replay where applicable. For OpenID Connect, an RP generally validates the ID token, including claims such as issuer, audience, and nonce where used. Note that a signed token is not necessarily an encrypted one; signing provides integrity and origin assurance, not confidentiality, so an RP should not assume the contents are hidden merely because they are signed.

How does an RP establish trust with an identity provider?

Trust is typically established by configuring the RP with the provider's metadata and signing keys so it can verify incoming assertions or tokens. In SAML 2.0 deployments this often involves exchanging metadata documents and certificates between SP and IdP. In OpenID Connect, an RP is commonly registered as a client with the provider, obtaining a client identifier and configuring redirect URIs, and it may consume the provider's discovery and JWKS endpoints to retrieve signing keys. The specific mechanics vary by vendor and configuration, and key rotation handling should be accounted for.

What should an RP do with the identity information after successful authentication?

After validating the assertion or token, the RP generally maps the received claims or attributes to a local session or user context, then applies its own authorization decisions before granting access to protected resources. Depending on the deployment, the RP may delegate authorization to a separate policy decision point or enforce it locally. The RP should treat identity attributes according to its trust in the source and its own data handling requirements, and provisioning of accounts from those attributes, if performed, is a governance concern distinct from the runtime authentication event itself.

Common misconceptions

A relying party performs the authentication of the user itself.

The RP delegates authentication to the identity provider and instead consumes and validates the result. Identification and authentication of the principal occur at the IdP; the RP verifies the returned assertion or ID token and typically establishes its own session from it.

An RP relying on OAuth 2.0 is authenticating users.

OAuth 2.0 is a delegated authorization framework and is not an authentication protocol. An RP that needs to authenticate a user relies on OpenID Connect, the authentication layer built on top of OAuth 2.0, and consumes the ID token defined by OIDC Core rather than treating an access token as proof of authentication.

If the token or assertion the RP receives is signed, its contents are confidential.

A signed token or assertion provides integrity and origin authentication, not confidentiality. Signing is not the same as encryption; depending on configuration, an RP may receive claims that are readable in transit unless the assertion or token is additionally encrypted or protected by transport security.

Best practices

Validate every token or assertion fully before trusting it: in OpenID Connect verify the ID token's signature, issuer, audience, and expiry, and for SAML 2.0 verify the assertion signature, conditions, and intended audience.

Register and strictly match redirect_uri (OIDC) or Assertion Consumer Service URLs (SAML 2.0) so responses cannot be redirected to unintended endpoints.

Maintain current trust material by regularly refreshing the identity provider's signing keys or certificates, using OIDC discovery/JWKS where available, and rotating keys according to your deployment's policy.

Keep authorization decisions separate from the authentication result: use the consumed claims to establish who the principal is, then apply your own access control model (such as RBAC, ABAC, or PBAC) to decide what they may do.

Apply encryption or transport protection where claim confidentiality is required, since a signed assertion or ID token is not confidential by signing alone.

Use the correct protocol layer for the goal: rely on OpenID Connect for user authentication rather than treating an OAuth 2.0 access token as proof of identity.