Home / Knowledge hub / Federated identity
Knowledge hub
Federated identity
Letting one organisation's sign-in be trusted by another's applications.
What it means
Federated identity means one organisation proves who a person is, and another organisation's application trusts that proof. The first is the identity provider, the second the relying party. NIST describes this in SP 800-63C, where the proof is passed as an assertion.
The person signs in once, with their own organisation or a large provider, and does not need a separate password for every application. Standards such as SAML and OpenID Connect carry the assertion between the two sides.
Why it matters
Customers and partners ask for it, and large buyers often make it a purchase condition: staff sign in with the company directory and lose access when they leave. It reduces password reuse and the number of accounts you must reset and secure.
It also moves trust. If your application accepts an assertion it should not have, or links accounts the wrong way, the attacker is let in by the system meant to protect it. The weak point is your handling of the assertion, not the provider.
How it shows up
You meet it as single sign-in for business customers, social sign-in buttons, and partner portals. In the application it appears as callback URLs, signed assertions or tokens, and rules for matching a federated person to a local account.
The mistakes repeat. Signatures are not checked, or only part of the message is covered. Accounts are matched on an unverified email address. Redirect addresses are loose. Every new customer's identity provider is trusted with the same rights. Check validation, account linking and what each provider is allowed to assert.
Questions people ask
Federated identity, answered
Is federated identity the same as single sign-on?
Related. Single sign-on is the experience of signing in once. Federation is the arrangement that lets separate organisations trust each other's sign-in, which is often how SSO is delivered.
You can have SSO inside one company without federation.
Which protocols are used?
The common ones are SAML and OpenID Connect, which builds on OAuth 2.0. Both pass a signed statement about the person from the provider to your application.
Your application must verify that statement fully.
What are the main risks?
Weak signature or token checks, account linking on unverified email addresses, loose redirect rules, and trusting a provider with more authority than it should have.
A compromised provider account can also become a way in.
Does federation replace our own authentication?
It replaces the password step for those users, not your responsibility. You still decide what each person may do, handle sessions, and keep a way to remove access.
Authorisation stays with you.
How do we test a federated sign-in?
Check that your application rejects tampered, expired or replayed assertions, that it ignores unsigned content, and that a person from one provider cannot take over an account made through another.
Test it with the real flow, not just the library defaults.
Sources
Where this comes from
Related
Terms that sit next to this one
Single sign-on
One company identity for many applications, granted and removed in one place.
SAML
An older XML standard for single sign-on between a company and its apps.
OpenID Connect
A sign-in layer on top of OAuth that tells your app who the user is.
Identity provider (IdP)
The service that signs people in and tells your app who they are.
SSO misconfiguration
A single sign-on setup that trusts the wrong issuer or accepts the wrong audience.
Who can your app be told to trust?
Sign-in flows that trust outside providers are worth testing end to end, including cross-account access between users. We prove each finding by exploiting it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.