Federation is not just Authentication: What's the difference and why it matters for your architecture?

Terms like authentication and identity federation are often used interchangeably. They’re related, but not the same thing. If you’re building apps, managing users across systems, it’s important to know the difference. Conflate the two can lead to poor design choices and security risks.

First, What’s Authentication?

Let’s start with the basics. Authentication is the process of answering a simple question: Are you really who you say you are?

This usually means logging in with something like:

• A password
• A fingerprint or face scan
• A phone that gets a push notification or one-time code

If you’ve ever typed your email and password into a login page—or used Face ID to open an app—you’ve been authenticated.

Then What’s Identity Federation?

Federation takes things a step further. It’s not just about proving who someone is, it’s about trusting another system to do it for you, and sometimes even creating a shared understanding of who that person is across systems.

Here’s what that might look like:

1. You log in to Google.
2. Then, you open your app and click “Log in with Google.”
3. That app doesn’t ask you to log in again. Instead, it trusts Google to vouch for you.

That’s federation: two systems (Google and the app) have a trust relationship. One handles authentication, and the other trusts the result.

But it's not just about authenticating people. Federation often involves:

• Creating a new user record in the destination system the first time someone logs in via a trusted identity provider.
• Linking identities across different systems so the same person can be recognized across platforms.
• Syncing identity attributes like name, email, name or group/role membership for authorization purposes.
• Optionally updating the user record each time they log in, to keep things in sync

Why This Matters (From an Architecture Perspective)

When you're building website, SaaS products, or mobile apps—you need to think beyond just "how do users log in?" and start thinking in terms of identity architecture.

Federation Isn't Just Login. It's How You Manage Identity. Authentication is "simple": you check a user’s credentials and let them in. Federation, on the other hand, affects the entire identity lifecycle in your architecture:

• It lets you offload authentication to a third party (like Google, Facebook, or a corporate IdP).
• But you still create and manage your own identity records inside your system.
• You decide what user data to store, how to link identities, and how often to sync attributes (like roles, permissions, or profile info).

So while federation may start with external authentication, it often ends with you owning the user identity—because that’s how you enforce access control, store preferences, and audit activity.

Architecture and security

Unlike basic authentication, federation isn’t always a plug-and-play solution. It requires trust relationships and secure backend handling.

Federation involves token exchange (like OIDC or SAML) between trusted parties. That means:

• Redirects, signed assertions, token validation
• Secure client secrets and backend logic
• Hosting a system capable of verifying identity tokens

This doesn’t work well directly in public-facing apps like:

• Single Page Applications (SPAs) written in JavaScript
• Native mobile apps

Why? Because you can’t safely store secrets or validate signed tokens purely on the client side. You need a backend component—often called a token broker or backend-for-frontend (BFF) to handle federation flows securely.

Lifecycle management

Federation also means you need to think about how and when identities are created, updated, and sometimes deleted across systems. When a user logs in via Google, you might create a new user record in your system and link it to their Google account. This identity creation or change process needs to be managed carefully, especially if you’re syncing attributes or roles. The moment your create or update a identity record is also important.

Here is how it usually works:

1. User logs in via third-party IdP (like Google).
2. Your system creates a new user record or updates an existing one. This new user has a unique identifier (like a UUID) in your system that’s linked to their Google account.
3. You sync attributes (like email, name, or roles) from the IdP to your system.
4. You should create a new session or token for the user in your system independently of the IdP.

Because of the sensitive nature of this process, you need to ensure that your system can handle these events securely and efficiently without exposing sensitive data or creating security holes. For this reason, you should always use a secure backend to handle these events. This is where a token broker or BFF (for public frontend) comes in handy.