What Federated Identity Actually Means

“Federated identity” gets used to mean single sign-on, social login, directory sync, and a half-dozen other things depending on who is talking. It is worth being precise, because the precise version is what makes identity manageable across many applications and organizations.

A working definition

Federated identity means that the place where a user is authenticated and the place where they are authorized do not have to be the same system — and that the trust between those systems is established deliberately, not assumed.

In practice, a user authenticates against the directory their organization already runs. Another system accepts the result of that authentication, on the basis of a trust relationship, and grants the user a session. The user is not re-created or re-credentialed in the second system. Their home directory stays the source of truth.

That is the whole idea: identity stays where it lives, and other systems consume it through standard, trusted protocols.

What it looks like in Veripass

Veripass is built around this principle rather than bolting it on. An organization keeps its existing identity provider — Microsoft Entra ID or Google Workspace — and Veripass federates with it over OIDC. Inbound authentication is handled through SAML and OIDC, so the user proves who they are to their own directory, and Veripass establishes the session from that assertion.

Lifecycle is federated too. Through SCIM, accounts are provisioned, updated, and deprovisioned from the upstream directory, so a person who is offboarded in the home directory loses access without anyone manually chasing them through every application.

A few things follow from this:

• Users are not duplicated. The home directory remains authoritative.
• Onboarding and offboarding happen once, in the directory, and propagate.
• The same person can be federated into multiple organizations without being recreated in each.

What federation is not

Being precise also means saying what federation does not do.

• It is not just SSO. Single sign-on is one benefit of federation, but federation also covers provisioning lifecycle and the trust relationship itself.
• It is not copying users between systems. The point is the opposite — to avoid duplicating identity and to keep one authoritative source.
• It is not authorization. Federation establishes who someone is; it does not decide what they may do. That is a separate layer.

That last distinction matters. In Veripass, once federation has established identity, authorization is handled by a composable model of claims, capabilities, roles, and access profiles, evaluated with context-aware policy. Federation gets you a trustworthy answer to “who is this,” and the authorization layer takes it from there — including demanding step-up MFA or biometric verification when a request is risky enough to warrant it.

Why the precision pays off

When federation is understood precisely — identity stays home, trust is explicit, lifecycle is automated, and authorization is a separate concern — you get an identity estate that scales without turning into a tangle of duplicated accounts. Directories stay authoritative, access stays governed, and every action stays attributable in the audit trail. That is what federated identity actually means, and it is the foundation everything else in the platform is built on.