Federation is an agreement between two systems: one proves who you are, and the other believes it.

The plain-English definition

Federation, in identity and access management, is a way of connecting separate systems so that a person can use one set of login details to reach many places. The word “federation” comes from the idea of a federation of states or groups that keep their own independence but agree to cooperate under shared rules. In the same way, each system in a federation keeps its own users, its own rules, and its own data, yet they agree to trust each other for the specific job of confirming who someone is.

The key phrase to remember is “trusted identity”. One system, called the Identity Provider, checks your password, your fingerprint, or your one-time code. The other system, called the Service Provider, does not check any of that. Instead, it accepts a signed message from the Identity Provider that says, “Yes, this is really Priya, and I have checked her.”

Where Okta fits in

Okta is a cloud service that specializes in identity. Companies use it to manage who their employees, partners, and customers are, and to control what those people can open. Federation is one of the core powers inside Okta. It lets Okta act as the trusted passport office for hundreds of applications, and it also lets Okta accept passports issued by other offices when that makes sense.

To understand why federation matters, picture life without it.

The world of too many passwords

Before federation became common, every application kept its own list of users and passwords. An employee at a mid-sized company might need email, a payroll system, a project tool, a customer database, a travel booking site, and a learning portal. That means six accounts, six passwords, and six different password rules. People responded in very human ways: they reused the same password everywhere, wrote passwords on sticky notes, or chose easy ones they could remember.

This created three big problems at the same time. Users were frustrated because they had to log in again and again. The help desk was overwhelmed with password reset requests. And security teams were worried, because one leaked password could unlock many systems. When someone left the company, administrators had to remember to remove that person from every single application, and forgetting even one left a door open.

The problem across company borders

The pain gets worse when two different organizations need to work together. Suppose a manufacturing company wants its supplier’s staff to use its ordering portal. Creating and managing separate accounts for hundreds of outsiders is slow and risky. What if the supplier already has a perfectly good way of checking its own employees? Federation lets the manufacturer say, “We will trust your login system for your own people.” The supplier keeps control of its staff list, and the manufacturer keeps control of what those staff can do inside the portal.

A few small words carry most of the meaning in federation. Learn these and the rest becomes easy.

Every field has its own language, and identity is no different. Do not worry if the words sound heavy. Each one has a simple meaning, and we will pair each with a plain description. Keep this chapter handy, because later chapters use these terms again and again.

Okta is flexible. Depending on the situation, it can be the one who vouches or the one who listens.

Role one: Okta as the Identity Provider

This is the most common picture. A company stores its workforce in Okta. Employees sign in to Okta, prove who they are, and then open applications such as Salesforce, Slack, or Workday without typing another password. Here, Okta is the Identity Provider, and each application is a Service Provider. Okta sends a signed assertion to each application saying, “This is a verified employee.”

Role two: Okta as the Service Provider

Sometimes the reverse happens. Okta itself accepts identities that were checked somewhere else. For example, a company might let users sign in to Okta using their Google or Microsoft account, or a partner organization might have its own identity system that Okta trusts. In Okta’s language, these outside sources are configured as Identity Providers inside the Okta admin area. When Okta trusts them, Okta behaves as the Service Provider in that relationship.

This is often called inbound federation, because identity proof comes in from outside. When Okta vouches for users to applications, that is called outbound federation from Okta’s point of view, because assertions flow out toward apps.

Two systems can only trust each other if they speak the same language. These languages are called protocols.

A protocol is a set of rules about how two systems talk to each other. If one system speaks French and the other speaks Japanese, they cannot cooperate. In federation, protocols decide what the signed message looks like, how it travels, and how it is checked. Okta supports several, and you will meet the first two most often.

SAML and OIDC side by side

Let us follow one person on their journey from clicking a link to seeing the application.

The most common flow is called Service Provider initiated, because the person starts at the application. Suppose Ananya wants to open a project tool that trusts Okta. Here is what happens behind the scenes, in everyday language.

sequenceDiagram
    participant U as User
    participant A as Application (SP)
    participant O as Okta (IdP)
    U->>A: Open application
    A->>U: Redirect to Okta
    U->>O: Arrive with sign-in request
    O->>U: Ask for credentials if no session
    U->>O: Prove identity
    O->>U: Return signed assertion
    U->>A: Deliver assertion
    A->>A: Verify signature and expiry
    A->>U: Grant access
        

Notice something beautiful here. The application never sees Ananya’s password, and Okta never needs to be told ahead of time which exact page she wants. The two systems only exchange signed messages, and each side checks what it needs to check.

The other way: Identity Provider initiated

In the second style, the person starts at Okta. Ananya signs in to her Okta dashboard, sees tiles for all her applications, and clicks one. Okta immediately builds a signed assertion and sends it to that application. Because the application did not ask for it, this style skips the first two steps of the earlier journey.

A signed message is only useful if the receiver knows whose signature to look for.

How trust is created

Trust in federation is not a feeling. It is a technical setup that two administrators complete together. They exchange a small package of details, called metadata, that includes addresses where messages should be sent, a name that identifies each side, and a public certificate. The certificate is like a specimen signature. The receiver keeps it on file and compares it against every signed message that arrives.

Public and private keys in simple words

Behind the signing lies a pair of mathematical keys. The private key stays secret with the Identity Provider and is used to sign. The public key can be shared with anyone and is used to check signatures. Anything signed by the private key can be verified by the public key, but nobody can forge a signature without the private key. That is why exchanging the public part during setup is safe.

This is the everyday face of Okta for most employees.

When Okta acts as the Identity Provider, administrators add applications to Okta and connect each one using SAML or OIDC. Okta maintains a large catalog called the Okta Integration Network, which contains thousands of ready-made connections to popular software. For many of these, the heavy lifting is already done, and an administrator mostly needs to confirm a few settings and assign the right people.

What the administrator controls

Federation is not only about login. It is also about control. Because every sign-in passes through Okta, administrators can decide who gets which application, how strong the login must be, and under what conditions access is allowed. For example, they can require a stronger second step when a person signs in from an unfamiliar country or from an unmanaged device.

Sometimes the passport comes from somewhere else, and Okta is the officer who checks it.

In inbound federation, an outside system is configured inside Okta as an Identity Provider. When a user chooses to sign in through that outside system, Okta sends them there, waits for the signed result, verifies it, and then signs them in to Okta. After that, the person can use everything Okta offers them, such as the dashboard and all connected applications.

Who uses inbound federation?

Routing: choosing the right door

When more than one outside Identity Provider is configured, Okta needs to decide which one a particular person should use. It does this with routing rules. A rule might say, “If the person’s email ends with the partner’s company name, send them to the partner’s login.” Another might say, “If the person is on the corporate network, use the internal system.” Good routing makes sign-in feel natural, because people are sent to the right place without having to choose.

Just-in-time account creation

What if someone arrives from an outside Identity Provider but has no account in Okta yet? Okta can create one on the fly, using the facts in the assertion. This is called just-in-time provisioning. It saves administrators from creating thousands of accounts by hand. However, it must be set up carefully, so that only the right kinds of people can be created and given the right access.

flowchart LR
    P1[Partner Staff] --> IDP2[Partner Identity System]
    S1[Social Account User] --> IDP3[Social Identity Provider]
    IDP2 --> OK[Okta]
    IDP3 --> OK
    OK --> APP1[Application A]
    OK --> APP2[Application B]
    OK --> APP3[Application C]
        

Okta often sits in the middle, acting as a hub between many identity sources and many applications.

Picture a railway station that connects many train lines. Passengers arrive from different directions, and the station directs them onward to many destinations. Okta can play that role in identity. Different groups of users arrive from different sources, such as the company’s own directory, a partner’s system, or social accounts. Okta checks and normalizes them, then passes trusted identity to the right applications.

graph TD
    D1[Company Directory] --> HUB((Okta Hub))
    D2[Partner Identity System] --> HUB
    D3[Social Accounts] --> HUB
    HUB --> A1[Business App 1]
    HUB --> A2[Business App 2]
    HUB --> A3[Customer Portal]
    HUB --> A4[Partner Portal]
        

Why the hub design is helpful

Without a hub, every application would need its own separate connection to every identity source. If you have five sources and ten applications, that could mean fifty separate connections to build and maintain. With a hub, each source connects once to Okta, and each application connects once to Okta. The number of connections drops to fifteen. Fewer connections mean fewer chances for mistakes and an easier time when something changes.

A good assertion carries more than a name. It carries the facts the application needs.

When Okta tells an application who the user is, it can also include extra facts, such as email address, first name, last name, department, job title, or group membership. These facts are called attributes in SAML and claims in OIDC. The application uses them to decide how to greet the person, which features to show, and what permissions to grant.

Why mapping is needed

Different systems name the same fact differently. One system may call it “mail,” another “emailAddress,” and a third “userPrincipalName.” Mapping is the act of telling Okta, “When you send this fact to this application, label it with the name that application expects.” Without careful mapping, an application may receive the right data under the wrong label and fail to recognize it.

The unique identifier matters most

Among all the attributes, one deserves special care: the identifier that tells the application which person this is. It is often the email address or a username. If this value changes, for example when someone’s email is updated after a name change, the application may think a new person has arrived and create a duplicate account. Choosing a stable identifier is one of the wisest decisions in any federation setup.

Three related ideas often get mixed together. Let us separate them gently.

Beginners frequently use federation, single sign-on, and provisioning as if they meant the same thing. They are neighbors, not twins. Each solves a different part of the identity puzzle, and a complete setup often uses all three together.

Federation concentrates trust in one place, which is powerful and also something to protect carefully.

Because many applications trust one Identity Provider, that Identity Provider becomes a very valuable target. If an attacker gains control of it, they might be able to open many doors. For this reason, security around the identity system must be stronger than around any single application. Here are the main protections people use.

Trust the source, not just the message

In inbound federation, there is an extra thing to consider. When you trust an outside Identity Provider, you are trusting their standards for checking people. If their process is weak, weak identities can reach your systems. That is why organizations carefully choose which outside providers to trust and limit what federated users can do until extra checks are met.

When sign-in fails, a calm, step-by-step look usually reveals the cause.

Federation involves at least two systems, so a failure can hide on either side. The good news is that Okta keeps a detailed activity record called the System Log. Every sign-in attempt, policy decision, and application access leaves an entry. Administrators read this log to see what happened, when, for whom, and why a request was allowed or denied.

A friendly troubleshooting path

What good monitoring watches

Federation brings great benefits, and a fair picture also shows what it costs.

Experience teaches a few habits that save a great deal of trouble later.

Habits worth building

Mistakes to avoid

Let us see how federation shows up in everyday business life.

Quick answers to questions beginners ask most often.

Not exactly. Single sign-on is what the user experiences: signing in once and reaching many applications. Federation is the trust arrangement between separate systems that often makes that experience possible, especially across organizations.

No. In federation, you type your password only at the Identity Provider. The application receives a signed statement saying you were verified, never the password itself.

The Identity Provider checks who you are and vouches for you. The Service Provider is the application or system that accepts that vouching and lets you in. Okta can play either role depending on the situation.

It means Okta accepts identity proof from an outside system, such as a partner’s login or a social account. Okta acts as the Service Provider in that relationship and then signs the person in to Okta.

Neither is better in every case. SAML is very common for established enterprise software, while OIDC is lighter and well suited to modern web and mobile applications. Choose based on what the application supports and what fits your needs.

People may be unable to start new sign-ins to the applications that depend on it. That is why organizations plan for availability, backup access methods, and clear recovery steps.

A common cause is an expired signing certificate, or a recent change to settings on one side that no longer matches the other. Checking certificate dates and comparing agreed details is a good first step.

No. Small teams benefit too, because fewer passwords and quicker onboarding help at any size. Larger organizations simply feel the savings more.

Yes. A person might sign in through their company account for work tools and a social account for a customer portal. Routing rules and careful design help keep this tidy and secure.

It stops new federated sign-ins, but an application that has already created its own session may keep it until it expires or is ended. Knowing each application’s session behavior helps you plan complete offboarding.

Federation is the quiet agreement that lets one trusted system vouch for a person to another. Instead of every application checking passwords on its own, one Identity Provider checks carefully and sends a signed statement that the others accept. Okta uses this idea in both directions: as the Identity Provider that sends trusted identity out to applications, and as the Service Provider that accepts trusted identity from outside sources such as partners and social accounts. Behind it all sit protocols like SAML and OIDC, certificates that prove messages are genuine, attributes that describe the user, and policies that keep access safe. When designed with care, federation gives people a smoother day, gives administrators stronger control, and gives organizations a safer way to cooperate.