Relying parties are the websites and applications that accept someone else’s verification of a user instead of checking credentials themselves. When a project management tool lets you in because your company’s identity provider vouched for you, that tool is acting as a relying party.
Most discussion of federated sign-in focuses on identity providers, yet many real-world failures happen on the receiving side. This guide is aimed at developers and administrators who build or configure relying parties, and at users who want to know what a trustworthy service should be doing with the identity information it receives.
The Service on the Receiving End of a Login
In any federated sign-in, the relying party starts the process. A user arrives without a session, so the relying party sends them to an identity provider with a request describing what it needs. The provider authenticates the user and returns a signed answer.
The term comes from the fact that this party relies on another’s statement. In SAML 2.0 the same role is called a service provider; in OpenID Connect it is often called a client. The names differ, but the responsibility is the same: receive an identity claim, decide whether to believe it, and decide what the user may do.
That last point is easy to overlook. An identity provider answers the question of who someone is. It does not decide what they may access inside your application. Authorization, meaning the rules about permitted actions, remains the relying party’s job, and no amount of strong authentication upstream fixes a weak permission model downstream.
Why the Relying Party Carries Real Responsibility
It is tempting to think that outsourcing sign-in also outsources security. In reality, a relying party that mishandles the provider’s answer can be tricked into accepting a forged or misdirected identity, even when the identity provider itself is flawless.
Consider a hypothetical scheduling app that accepts any token it receives without checking who issued it or who it was meant for. An attacker who obtains a valid token issued for a different application could replay it and be signed in as the victim. The provider did nothing wrong; the relying party simply failed to check.
Relying parties also hold the data that users care about most: messages, files, payment details and records. Federation removes passwords from their systems, which is helpful, but every other protection still applies. Secure storage, sensible permissions, logging and timely patching are as important as they were before federated sign-in arrived.
Registering a Relying Party With a Provider
Before any user signs in, the relying party and identity provider must know each other. This registration step establishes the technical trust that every later sign-in depends on, so it deserves care rather than copy-and-paste haste.
- Identifiers: a unique client ID or entity ID that names the relying party to the provider.
- Redirect addresses: the exact URLs where the provider may send responses, with no broad wildcards.
- Keys or secrets: client secrets or key pairs, stored in a secrets manager rather than in source code.
- Requested attributes: the minimum set of user details the application genuinely needs.
- Provider metadata: the provider’s signing keys and endpoints, ideally fetched automatically from a published source.
Overly permissive redirect addresses are a classic weakness. If a provider will send tokens to any page on a domain, an attacker who controls one page there may be able to collect them. Register exact addresses and remove test entries before going live.
Before go-live, ask the identity provider administrator to confirm that the registered details match production values, not leftovers from a test environment.
Validating Every Assertion or Token
Validation is the relying party’s most important technical duty. Each response from the identity provider must be checked before it creates a session. Well-maintained libraries perform these checks, but developers should understand them well enough to confirm they are switched on.
Signature and Issuer Checks
The relying party verifies the digital signature on the SAML assertion or OpenID Connect ID token using the provider’s published public key. It also confirms the issuer field matches the provider it expected. A response signed with an unknown key, or claiming to come from a different issuer, must be rejected without exception or fallback.
Audience and Recipient Checks
Every assertion or token names its intended audience. The relying party must confirm that audience is itself, not some other application. This check stops an attacker from taking a valid token issued to one service and presenting it to another. Skipped audience validation is a well-known source of real-world vulnerabilities.
Time Limits and Replay Protection
Assertions and tokens include issue and expiry times, and the relying party should reject anything outside a narrow window, allowing only small clock differences. OpenID Connect uses a value called a nonce, and SAML uses request identifiers, to tie each response to a specific request so captured responses cannot be replayed later.
Requesting Only the Attributes You Need
Every attribute a relying party receives becomes data it must protect, retain responsibly and possibly disclose in a breach. Asking for less is the simplest privacy and security improvement available. Begin each integration by listing what the application genuinely uses.
A discussion forum might need only a stable identifier and a display name. A training platform might need an email address for notifications and a department for reporting. Neither needs a phone number, birth date or home address. In OpenID Connect, attributes arrive through scopes and claims, so request narrow scopes rather than broad profile access.
Data minimization also helps users trust the consent screen. When a sign-in prompt asks for unexpected details, cautious users abandon it, and they are right to. Laws such as GDPR expect personal data collection to be limited to what is necessary, so asking for less also simplifies compliance conversations.
Linking Federated Identities to Local Accounts
Most relying parties keep a local user record for preferences, permissions and content ownership. The question is how to connect each incoming federated identity to the right local record, consistently and safely, even as user details change over time.
The safest key is the provider’s stable subject identifier combined with the issuer, not an email address. Email addresses change, can be reassigned and are sometimes unverified at the provider. Matching on email alone has let attackers register an address at a weaker provider and take over an existing account elsewhere.
When an existing local account needs to be linked to a new federated sign-in, ask the user to prove control of both, for example by signing in with the old method first. Record which provider and subject are linked, and show users their linked sign-in methods so they can spot and remove anything unfamiliar.
Managing Sessions After the Handoff
Once validation succeeds, the relying party creates its own session, usually with a secure cookie. From that moment the identity provider is no longer involved in each request, so the relying party controls how long access lasts and when to ask again.
Set session lifetimes by sensitivity. A news reader can remember users for weeks, while an administration panel should expire after a short idle period. Mark cookies as secure and HTTP-only so they travel only over encrypted connections and cannot be read by page scripts, which reduces theft through injected code.
Plan for revocation too. When a user signs out, end the local session fully. Where the provider supports logout notifications or session status checks, use them so that a disabled account at the provider does not keep working for hours. For sensitive actions, request fresh authentication from the provider rather than trusting an old session.
Common Relying Party Mistakes to Avoid
Security reviews of federated applications tend to find the same small set of problems. Most are configuration choices rather than deep design flaws, which means they are cheap to fix once someone looks for them deliberately.
- Accepting unsigned responses, or trusting a signature without confirming the key belongs to the expected provider.
- Skipping audience, issuer or expiry checks because a library default was changed during testing.
- Matching accounts on email address instead of the issuer and subject identifier.
- Storing client secrets in code repositories or shared configuration files.
- Leaving local password sign-in enabled as a silent bypass around federated controls.
Each of these can be caught with automated tests that feed deliberately broken responses to the application and confirm they are rejected. Running those tests on every release prevents a convenient debugging shortcut from quietly reaching production.
A Worked Example: A Community Clinic Booking Site
Imagine a hypothetical clinic that builds an appointment booking site and lets patients sign in through a regional identity provider instead of creating new passwords. The booking site is the relying party, and it handles sensitive health-related scheduling information.
The developers register exact redirect addresses, request only a subject identifier, name and email address, and use a maintained OpenID Connect library with signature, issuer, audience, expiry and nonce checks enabled. Local accounts are keyed on issuer plus subject, never on email alone.
Sessions expire after a short idle period, and changing contact details requires a fresh sign-in. Logs record each federated sign-in without storing tokens. Before launch, a tester submits expired, tampered and wrongly addressed tokens to confirm all are rejected. The result is convenient for patients and resistant to the most common relying party attacks.
What Users Should Expect From a Trustworthy Service
Users cannot inspect a relying party’s code, but they can observe its behavior. A trustworthy service asks for a modest set of details on the consent screen, explains why it needs them and does not demand broad access to contacts, files or messages to provide a simple function.
It should also show which sign-in methods are linked to your account and let you remove them. It should ask you to sign in again before sensitive changes, such as updating payment details. When you sign out, you should actually be signed out, not silently signed back in on the next visit.
If a service fails these basic expectations, consider limiting what you store there. You can review and revoke a service’s access from your identity provider’s connected applications page, which stops future sign-ins and attribute sharing, although data already held by the service may require a separate deletion request.
Users who want stronger control can also choose separate sign-in accounts for sensitive services, so a problem with one identity provider does not affect everything at once.
A Release Checklist for Your Next Relying Party
Before launching or updating a relying party, walk through a short checklist. Confirm registration uses exact redirect addresses, secrets are stored securely and provider metadata refreshes automatically so key rotations do not cause outages or stale trust.
Confirm validation covers signature, issuer, audience, expiry and replay protection, and that tests prove broken responses fail. Confirm attribute requests are minimal and documented, accounts link on issuer plus subject, and any local password fallback is disabled or tightly restricted to emergency use.
Confirm sessions have sensible lifetimes, cookies are protected, sign-out works and sensitive actions trigger reauthentication. Review this checklist whenever the identity provider, library or application changes. A relying party that treats every incoming identity claim as something to verify, rather than something to accept, gives federation the strong foundation it was designed to have.