Identity federation explained: one login, many services

Identity federation means that one organisation, the identity provider, confirms who you are to other organisations, called relying parties or service providers, which accept that confirmation instead of keeping their own password for you. When you log in to a work application through your employer’s account, or reach a journal through your university login, you are using federation.

How does federation work?

Three ideas are involved:

1. A trust relationship. The service decides in advance which identity providers it accepts. This is configured technically, by exchanging keys and endpoint addresses (SAML calls this metadata), and legally, by contracts or by membership in a federation.
2. A login redirect. When you open the service, it sends you to your identity provider. You authenticate there, with a password, a passkey or a second factor.
3. A signed assertion. The provider sends the service a signed message saying who you are and, optionally, a few attributes such as name, email or group membership. The service verifies the signature and creates a session.

The service never sees your password. The provider decides how strongly to authenticate you, and can apply the same security rules everywhere.

Which standards are used?

Standard	Format	Typical environment
SAML 2.0	XML assertions	Enterprises, universities, public administration
OpenID Connect	JSON, JWT, built on OAuth 2.0	Consumer web, mobile apps, modern enterprise apps
WS-Federation	XML	Older Microsoft environments
OpenID 2.0	URL-based identifiers	Legacy, now largely retired

OpenID Connect is specified by the OpenID Foundation. SAML 2.0 is maintained by OASIS.

Forms of federation

• Enterprise federation. A company connects its directory to dozens of cloud services. Our page on single sign-on shows the user side.
• Social login. Large consumer platforms act as identity providers for any website that wants to use them.
• Research and education federations. National federations connect universities and libraries; eduGAIN links many of them internationally, so a researcher can use their home login abroad.
• Government federations. Countries run national eID schemes, and the EU connects them through the eIDAS interoperability framework: a service in one Member State can request authentication from the eID scheme of another through national nodes. The page on cross-border eID explains this.

Federation and the EUDI Wallet

In federation, the identity provider is typically involved at every login. In the wallet model defined by the revised eIDAS Regulation, the user holds credentials in their own device and presents them directly to a service; the issuer does not take part in each presentation. The service plays the role the OpenID world calls a relying party, and it must be registered (see What is a relying party?). The presentation protocol is OpenID for Verifiable Presentations.

This changes the privacy profile: a classic provider can see every service you use, while the issuer of a wallet credential cannot. It also changes the user experience, because the wallet works the same way across services and countries.

Federation does not disappear. Employers, universities and banks will keep using it for logins, and the wallet is likely to be accepted as one way to prove identity at an identity provider. Read the EUDI Wallet overview for how the two fit together.

Why organisations choose federation

For organisations, federation moves password handling, multi-factor checks and account recovery to one hardened place. Security teams can enforce one policy, switch off one account when someone leaves, and see sign-in logs in a single system. For users it means fewer passwords to remember and fewer places where a leaked password does damage. For service providers it means less to secure: a service that never stores passwords cannot leak them.

The costs are real as well. Setting up trust takes work, attribute mappings differ between partners, and every federation needs someone responsible for keeping certificates and metadata current. Expired signing certificates are among the most common causes of sudden login outages in SAML setups.

Examples

• Employee access. A staff member uses one corporate login for email, HR portal and expenses tool.
• Library access. A student opens a publisher’s site, selects their university and signs in there.
• Tax filing. A citizen in one country uses their national eID to access a service run by another Member State through the eIDAS network.

Security considerations

• The identity provider is critical. If an attacker takes over the provider or your account there, every connected service is exposed. Protect it with phishing-resistant authentication, such as passkeys or hardware security keys.
• Validate everything. Services must check signatures, audience, expiry and the intended recipient of every assertion. Many real vulnerabilities stem from skipped checks.
• Limit attributes. Send only the attributes a service needs.
• Plan recovery. If the provider is unavailable, users should not be locked out of everything. Account recovery is a separate topic with its own risks.
• Mind the privacy impact. A central provider learns when and where you log in. Pairwise identifiers, which differ per service, reduce cross-service tracking.

How does it compare with other approaches?

Local accounts give each service its own password, so users juggle many credentials and breaches multiply. Federation reduces that, at the cost of concentration. Decentralised models such as decentralized identifiers and wallets distribute control to the holder, at the cost of new complexity and a new ecosystem.

Status in October 2026

SAML 2.0 and OpenID Connect are mature and widely deployed. The EU is building wallet-based identity on top of the existing eID infrastructure rather than abolishing it, so expect hybrid setups, with federation for ongoing logins and wallets for identity proofing and attribute sharing.