What Is Federated Identity? A Plain Guide

Federated identity is an arrangement where one system holds your account and vouches for you to other systems, so a single login opens many separate services. The system holding the account is the identity provider. The services that agree to trust it are the relying parties. If you have ever clicked Sign in with Google on a site that has nothing to do with Google, you have used federated identity.

The word federated is doing real work here. The services stay separate. They keep their own data, their own rules and their own admins. The only thing that crosses between them is a short, signed statement saying who you are and when that statement expires. That is a very different design from one giant account system that owns everything, and it is also different from the way the fediverse uses the word, which we cover further down.

How federated identity actually works

Think of a festival wristband. You show a passport once at the gate, staff check it, and you get a wristband. For the rest of the weekend the bar, the campsite and the stage crew look at the wristband, not your passport. They trust whoever runs the gate. Federated identity works the same way: one place checks you carefully, then issues proof that everywhere else accepts.

A single login looks like this:

• You open a service, say a self-hosted Nextcloud, and click sign in.
• Nextcloud redirects your browser to the identity provider.
• You authenticate there with a password and a second factor, or with a passkey.
• The provider sends your browser back carrying a short, cryptographically signed token.
• Nextcloud checks the signature, reads the claims inside, and starts a session.

The important part is what did not happen. Nextcloud never saw your password and stores no password hash for you, so a breach of Nextcloud cannot leak your credentials. The token usually carries a stable user identifier, an email address, a display name, group memberships and an expiry time, and nothing else.

Federated identity, single sign-on and social login are not the same thing

These terms get swapped around in marketing copy, and the differences matter when choosing software.

Single sign-on is the feeling. Federation is the plumbing that makes the feeling possible across organisational boundaries. You can have federation without smooth single sign-on, if sessions are short or a service demands a fresh factor every time.

The protocols: SAML, OAuth 2.0, OpenID Connect and LDAP

Four standards do almost all of the work, and they are not interchangeable.

• SAML 2.0 is an OASIS standard finalised in 2005 that passes signed XML assertions through the browser. Verbose and elderly, but still the backbone of universities, government and large enterprises. Shibboleth is the classic open-source implementation.
• OAuth 2.0 is authorisation, not authentication. It answers may this app read my calendar, not who is this person. It is a valet key, not an ID card. Bolting a login onto raw OAuth 2.0 is a well-known source of security bugs.
• OpenID Connect is a thin identity layer on top of OAuth 2.0, published by the OpenID Foundation in 2014. Claims arrive in a signed JSON web token. This is what nearly all modern self-hosted software speaks.
• LDAP and Kerberos are the directory and the ticketing system inside one organisation. Not federation, but very often the source of truth an identity provider reads from.

If you are wiring up your own services, pick OpenID Connect and fall back to SAML only when an application speaks nothing else. OIDC tokens are readable JSON and the flows are easy to trace in a browser network log.

Federated identity in the fediverse means something different

The word federated carries a second meaning that trips people up. In the fediverse, which covers Mastodon, Akkoma, Pixelfed, PeerTube and anything else speaking ActivityPub, your identity is an address like @[email protected]. The server named in that address holds your account and signs the messages it sends on your behalf, so other servers can verify a post genuinely came from you.

That is federated identity in the broad sense, but it is not the same machinery as OpenID Connect. You never log in to somebody else's Mastodon server. Your server talks to theirs while you stay signed in at home. Matrix works on the same principle with homeservers, and a Matrix ID is shaped the same way.

The practical difference shows up when you want to leave. Mastodon can redirect an old account to a new one and carry your followers across, but your old posts stay behind on the original server.

Both meanings sit under the same larger question of data sovereignty. Whoever holds the account holds real power over you, whichever protocol they use.

Running your own identity provider

Self-hosting the provider is the version of federated identity where you are the trusted party. The mature open-source options are Keycloak, backed by Red Hat and common in enterprises; Authentik, which has a friendlier admin interface and good support for forward-auth proxying; Zitadel and Kanidm, both newer and lighter; and Authelia, which is less a full provider than a gate you put in front of a reverse proxy.

We run Authentik for the WOPR Foundation's own services, so what follows is a description of the work rather than a sales pitch.

• Put the provider behind a reverse proxy such as Caddy or nginx, on its own hostname, with real TLS.
• Create one application and one provider entry per service, then map groups to permissions inside each service.
• Require a phishing-resistant second factor. WebAuthn passkeys are the strong option; TOTP codes are the acceptable minimum.
• Keep one local admin account on every critical service, with the password written down offline.
• Back up the provider database and test the restore. If it is gone, every downstream login is gone with it.

What federated identity is bad at

This is the section most vendor pages skip.

• It is a single point of failure. When the provider is down, nothing opens. Not the wiki, not the file server, not the ticket system. Break-glass local accounts and a monitored uptime check are not optional extras.
• One compromised account opens every door. Federation concentrates risk by design. That is why passkeys, short session lifetimes and alerts on new-device logins matter more here than on a standalone service.
• The provider sees everything. Every login, to every service, with a timestamp. When the provider is an advertising company, that is a behavioural profile. When it is your own server, it is still a log, and you now have a duty to protect it.
• Portability is worse than it sounds. Many applications key a user record to the subject identifier the provider sent. Change providers and the service may not recognise the returning user at all.
• It is fiddly to debug. Clock skew, redirect URI mismatches, expired signing certificates and stale metadata all cause failures that look identical from the outside.
• It is not anonymity. Federated identity exists to prove who you are, which is the opposite goal. Systems that need eligibility without identity, such as secret ballots, have to separate the two on purpose, the way Folkmoot checks eligibility apart from the ballot itself.

Sign in with Google is federated identity, and that is the problem

Consumer social login is technically sound. Google, Apple and GitHub run OpenID Connect competently, their infrastructure is reliable, and for someone who would otherwise reuse one password across forty sites, social login is a genuine security improvement.

The cost is not cryptographic, it is structural. Your identity provider is an advertising company, and every downstream login is a signal about what you do and when. If the account is suspended by an automated system, you lose the account and every service that depends on it in the same moment, usually with no human to appeal to.

The upgrade path is boring and effective. Move to a password manager with unique passwords and passkeys. Where a service offers a direct account alongside social login, take the direct account. If you run services for a household, a club or a small organisation, that is the point where your own identity provider starts to pay for itself. Our step-by-step guide to leaving Google covers the order to do that migration in.

Federated identity on a community or mesh network

There is one situation where self-hosted federation is not an ideological preference but plainly the better engineering: a network that can lose its uplink. If the identity provider sits on a server inside a neighbourhood mesh network, logins to the local file share, chat and map keep working when the fibre is cut or the grid goes down. A cloud provider gives you nothing at that moment. Off-grid LoRa gear such as the kits from Blackout Labs assumes exactly that world, where the internet is the optional part.

Two practical warnings. Certificates and clocks do not care about your outage. TLS certificates from Let's Encrypt need reachability to renew, and token validation fails when device clocks drift, so a local time source and a plan for long-lived internal certificates belong in the design from the start.

The second warning is not technical. Whoever administers the identity provider can reset anyone's account and read the login history. In a co-op or a community group, write down who holds that power, how they are chosen and how they can be removed, before anybody needs to ask.

A practical checklist for federating your own services

Start small. A federation project that begins with the most critical service is how people end up locked out of their own infrastructure on a Sunday night.

1. List every service and note which protocols it supports. Most will offer OpenID Connect, a few will be SAML only, and some will have nothing but local accounts and LDAP.
2. Stand up one provider on its own hostname, with TLS and working backups, before connecting anything to it.
3. Connect one low-stakes service first, such as a wiki or a status page, and live with it for a week.
4. Turn on passkeys or TOTP at the provider, then shorten session lifetimes to something you can tolerate.
5. Create break-glass local admin accounts everywhere, store the recovery codes offline, and put a date in the calendar to test them.
6. Only then migrate mail, file storage and anything holding money.

If you are working out where identity fits into a wider move away from rented platforms, the rest of our guides cover the neighbouring pieces: self-hosting, mesh networking and what owning your own data actually requires.

Frequently asked questions

Is federated identity the same as single sign-on?

No, though they usually travel together. Single sign-on describes the experience of logging in once and not being asked again during a session. Federated identity is the underlying arrangement in which one system vouches for you to other, separate systems. Federation is what makes single sign-on possible across organisations rather than only inside one application.

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 handles authorisation: it lets an application act on your behalf against an API, such as reading your calendar. It never reliably answers who you are. OpenID Connect adds a thin identity layer on top, returning a signed token with claims about the user. If you want a login rather than API access, use OpenID Connect.

Is federated identity more secure than separate passwords?

Usually yes, with one caveat. Services never store your password, so a breach at any one of them cannot leak your credentials, and you can protect the single account properly with a passkey. The caveat is concentration. If that one account is compromised, every connected service is compromised at once, so phishing-resistant second factors are essential.

What happens if the identity provider goes offline?

Nobody can start a new session anywhere. Existing sessions survive until their tokens expire, often minutes to hours, and then everything stops. This is the main operational risk of federation. Reduce it by keeping local break-glass admin accounts on critical services, monitoring the provider from outside, and testing your database restore before you need it.

Can I move my accounts to a different identity provider later?

Sometimes, but expect friction. Many applications tie an existing user record to the subject identifier the old provider issued, so a new provider looks like a stranger even with the same email address. Check whether each service lets an admin re-link accounts or match on email address, and plan a migration window before you commit.

Do I need federated identity for a handful of personal services?

Probably not. For a few self-hosted apps used by one person, a good password manager with unique passwords and hardware-backed passkeys is simpler and has no single point of failure. Federation starts paying off around the point where several people share several services and account creation, group membership and offboarding become recurring chores.