Home / Knowledge hub / Identity provider (IdP)
Knowledge hub
Identity provider (IdP)
The service that signs people in and tells your app who they are.
What it means
An identity provider, or IdP, is the service that holds user accounts and checks passwords or other proofs. When someone signs in, it hands your app a signed statement saying who they are, instead of your app handling the password itself. The sign-in screen, the password check and the second factor all live there.
Your app trusts that statement because it is signed. It is the relying party in the exchange. Common protocols are OpenID Connect, which uses signed tokens, and SAML, which uses signed XML. Think of it as a passport office that your app trusts to stamp the right name.
Why it matters
Using one moves a hard problem out of your code. Password storage, multi-factor sign-in and account recovery are done once, by a service built for it. Enterprise customers also expect to connect their own provider through single sign-on. You also get consistent policies, such as forcing a second factor, without changing your own code.
It also makes your app trust something. If your app accepts a statement from the wrong issuer, for the wrong audience, or without checking its signature, anyone who can produce one becomes any user they like. That trust is the thing to test, because everything after sign-in depends on it.
How it shows up
You meet it as a login redirect, a callback endpoint and a set of settings: issuer, client identifier, redirect addresses and keys. The callback must check the signature, the issuer, the audience and the expiry before it creates a session. See OpenID Connect and SAML. Each setting is a place where a small mistake widens who gets in.
Repeated mistakes: trusting an email address from any provider without checking it is verified, allowing wide redirect address patterns, and linking accounts by email alone. Each can end as account takeover. Test each of these on the running app, not just in the settings.
Questions people ask
Identity provider (IdP), answered
Is an identity provider the same as an authentication server?
Close, in common use. The identity provider proves who the person is. In OAuth terms the server that issues tokens may be separate from the one that holds accounts, though many products combine them. Your own app only needs to know which one it is dealing with.
Should we build our own or buy one?
For most businesses, use an established one. Building sign-in is a lot of security-sensitive work. You still have to configure and test your side of the connection correctly.
What does our app have to check?
The signature, the issuer, the audience, the expiry and, in OpenID Connect, the nonce. Skipping any of them can let a statement meant for something else be accepted. Treat each as a required step, not an optional hardening measure.
Can an identity provider be compromised?
Yes, and then everything that trusts it is exposed. Limit what the provider can assert, keep sessions short for sensitive actions and log sign-ins on your side as well.
Is it the same as single sign-on?
Not quite. Single sign-on is the experience of signing in once for many apps. The identity provider is the service that makes it possible. People often use the two words as if they were one, and the difference only matters when you are configuring it.
Sources
Where this comes from
Related
Terms that sit next to this one
Single sign-on
One company identity for many applications, granted and removed in one place.
OpenID Connect
A sign-in layer on top of OAuth that tells your app who the user is.
SAML
An older XML standard for single sign-on between a company and its apps.
SSO misconfiguration
A single sign-on setup that trusts the wrong issuer or accepts the wrong audience.
Federated identity
Letting one organisation's sign-in be trusted by another's applications.
What does your app trust from it?
The sign-in callback is a common place for logic flaws, and we test it on the running app and prove what a forged or mismatched statement can reach. Each finding carries the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.