What is an identity provider?

Every time you click a button that says sign in with your work account, something invisible happens behind it. The app you are trying to open does not check your password itself. It hands the question off to a separate system that already holds your identity, waits for that system to confirm you are who you claim to be, and then trusts the answer it gets back. That separate system is the identity provider, usually shortened to IdP, and it is one of the most important pieces of software most people never see.

Understanding the IdP is the key to understanding how single sign-on works, why large organizations centralize their logins, and why offboarding a departing employee can be as simple as flipping one switch. This post explains what an identity provider does, the trust model that lets one system vouch for you to many others, why centralizing identity is a security decision as much as a convenience, and where a work tool like the one I build fits into the picture without pretending to be something it is not.

What an identity provider actually does

Strip away the jargon and an identity provider has one core job: to answer the question "is this really who they say they are" on behalf of many applications at once. It stores the accounts, holds or checks the credentials, enforces the login rules such as requiring a second factor, and produces a trustworthy statement that a given person has been authenticated.

That statement is the product. When you sign in through an IdP, it does not hand your password to the app you are opening. It performs the check itself and then issues a signed token or assertion, which is a short, tamper-evident message that says, in effect, "this is Farhan, I verified them just now, and here is proof you can check." The app reads that message, confirms the signature is genuine, and lets you in. Your password never travels to the app at all, which is a large part of why this design is safer than every app holding its own copy of your credentials.

An IdP typically does more than authenticate. It holds a directory of who works at the organization, which groups they belong to, and what attributes describe them, such as department or job title. That directory becomes the single record of who exists, which turns out to matter enormously the day someone leaves.

The trust model that makes SSO possible

Single sign-on rests on a relationship between two roles. On one side is the identity provider, the authority that verifies people. On the other is the service provider, which is any application a person wants to use, sometimes called the relying party because it relies on the IdP's word. The whole system works because the service provider has agreed, in advance, to trust assertions signed by that specific identity provider.

Here is the sequence in plain terms. You try to open an app, the service provider. It sees you are not signed in and redirects you to your identity provider. The IdP checks your credentials, applies any extra rules like a second factor, and if you pass, sends you back to the app carrying a signed assertion. The app checks the signature against the IdP's public key, confirms it has not been tampered with or reused, reads who you are from inside it, and grants access. All of it happens in the time it takes a page to load.

The signature is what makes this safe. Because the assertion is cryptographically signed by the IdP, the service provider can be certain it came from the authority it trusts and was not forged by an attacker in the middle. This is the same trust model whether the underlying standard is SAML or OpenID Connect. If you want the broader view of how one login opens many tools, I cover it in the guide to what single sign-on is, and the reasons enterprises insist on it in the piece on why buyers ask for enterprise SSO.

Common identity providers

Several products dominate this space, and each grew from a slightly different starting point. The differences matter less than the shared role: all of them authenticate people and vouch for them to other applications. Here is a neutral look at the ones you are most likely to meet.

Two of these are worth a note. Microsoft Entra ID and Google Workspace are identity providers that many organizations already own because they came bundled with email and documents, which is why so many companies use one of them as their IdP without buying anything extra. Okta and Ping, by contrast, exist mainly to be the identity layer itself and to connect cleanly to a wide range of apps. There is no single best choice. The right one depends on what an organization already runs and how much it needs to connect.

Why centralizing identity matters

It would be possible to let every app hold its own list of users and passwords. Many small setups still work that way, and it becomes a quiet disaster as an organization grows. An identity provider fixes this by making one system the source of truth for who exists, and the benefits compound.

The first benefit is security. When credentials live in one well-defended place instead of scattered across dozens of apps, you have one door to protect rather than dozens, and you can enforce strong rules like mandatory multi-factor authentication in a single spot. You also stop the sprawl of forgotten accounts sitting in tools nobody audits.

The second benefit is offboarding, and this is the one that keeps security teams up at night. When someone leaves, you want their access to every tool gone immediately, not gone from the ones somebody remembers to check. With a central identity provider, disabling one account cuts off access to every connected application at once. Without it, a departed employee might keep working access to a handful of tools for weeks, which is exactly the kind of gap that turns into an incident. This is least privilege applied to the whole lifecycle of an account, a discipline I have written about in least privilege in practice.

The third benefit is simply that people hate managing many passwords, and when they hate it they reuse one weak password everywhere, which is worse for everyone. A central login removes the reason to do that.

Where a work tool fits, honestly

It is easy to blur the line between an identity provider and an application that uses one, so let me be exact about the category, because the honesty is the point. An identity provider issues and verifies identities. A work tool consumes them. wrxstack is firmly in the second group. Atlas, the AI work platform I build, is a service provider. It connects to whatever identity provider your organization already runs, through standard single sign-on, so your people sign in with the account they already have and your existing rules apply at the door.

What that means in practice is that wrxstack does not try to be your identity provider, and I would not claim it is one. It does not run your directory, it does not replace Entra or Okta or Google, and it does not offer directory synchronization or user provisioning of its own. It sits on the trusting side of the relationship and honors the identity your IdP vouches for. Inside the product, the assistant then acts under the acting person's own permissions, so a login through your provider carries through to what the assistant is allowed to do on that person's behalf. You can see exactly what is and is not in place on the security page, and how the product is positioned on the Atlas page. Being clear about which side of that line a product lives on is, to me, part of being trustworthy at all.

How to think about choosing one

If you are picking an identity provider for an organization, the deciding factors are usually practical rather than technical. Start with what you already own, because using the IdP bundled with your email suite is often the simplest and cheapest path. Consider how many outside apps you need to connect, since a dedicated platform earns its keep when you have many. Weigh how strict your login rules need to be and whether the provider can enforce them cleanly across everyone. And factor in how offboarding will actually work, because the value of centralizing identity shows up most on the day someone leaves.

It also helps to separate two decisions people often merge. One is which identity provider will hold your accounts and enforce your login rules. The other is which apps you will connect to it. The first is a long-term commitment, because migrating an IdP later is real work and touches everyone. The second is easy to change, because a well-built app connects to any standard provider through the same mechanism. Choose the provider carefully and treat the apps around it as replaceable, and you keep your options open as your needs shift.

Whatever you choose, the mental model stays the same. The identity provider is the trusted authority that knows your people and vouches for them. Every well-behaved app, including the one I build, should be content to trust that authority rather than trying to become it.