What is an Identity Provider (IdP)?

An Identity Provider (IdP) is an external service – such as Okta, Microsoft ADFS, Azure AD, OneLogin, or Ping Identity – that authenticates users and issues signed assertions confirming their identity. A service provider, such as a Versa Director or Concerto login, trusts those assertions to grant or deny access without directly managing user credentials.

Key takeaways

• IdPs authenticate users and issue signed assertions to service providers.
• SAML and OpenID Connect are the two standard assertion formats.
• SP-initiated and IdP-initiated are the two SSO login flows.
• Versa Director, Concerto, and application reverse proxy all consume IdP assertions.
• Common IdPs include Okta, Azure AD, ADFS, OneLogin, and Ping Identity.

On this page: Why it matters · How it works · Types · IdP & Versa · FAQ

Why is an IdP important?

Every application a user touches – Director, Concerto, a SaaS tool, an internal web app – needs to know who that user is. Without a shared identity provider, each service manages its own password store, and every hire or departure means updating credentials across disconnected systems – a liability: stale accounts, weak passwords, no single point to enforce MFA or revoke access instantly.

An IdP centralizes authentication instead. Users authenticate once, and the IdP vouches for them to every trusting service – a service provider like Director never sees or stores the password. That centralization makes MFA and device-posture checks enforceable at one point, and makes the IdP the first checkpoint in Zero Trust: reverse proxy and ZTNA gateways rely on its assertion before granting access.

What is an IdP?

An IdP is the party in an authentication exchange that verifies a user’s credentials and issues a signed assertion confirming who they are and, often, what attributes apply (role, organization, group). The counterpart is the service provider (SP); it trusts the signature and never handles the password directly.

Two standards carry this exchange. SAML is an XML-based format where the IdP and SP exchange metadata in advance, and the IdP returns an assertion after authentication. OpenID Connect, built on OAuth 2.0, uses a JSON web token and fits API-first integrations. Either can run SP-initiated (the user starts at the application, redirected to the IdP) or IdP-initiated (already authenticated at the IdP’s portal).

The IdP’s signing certificate and clock sync with each connected SP keep the chain valid.

Types of IdPs

IdPs fall into a few categories. Cloud-hosted IdPs – Okta, Microsoft Entra ID (Azure AD), OneLogin, Ping Identity – run as managed SaaS; an organization configures users through the vendor’s console, and the IdP handles uptime and certificate rotation. On-premises IdPs, such as Active Directory Federation Services (ADFS), run inside the organization’s own infrastructure, trading that convenience for control over data residency and directory integration.

A second axis is protocol support: some IdPs speak only SAML, some only OpenID Connect, and most enterprise-grade IdPs – including all five tested against Director and Concerto – speak both. A third pattern is the broker IdP, federating to upstream IdPs; Versa’s application reverse proxy uses this pattern, sitting between a SaaS provider and the real IdP so policy can be enforced in between.

IdP & Versa

Director and Concerto both authenticate administrators against an external IdP, instead of or alongside local accounts. Configuring single sign-on in Director or single sign-on in Concerto means uploading the IdP’s metadata XML, entering the SP entity ID and ACS URL, and mapping SAML or OpenID Connect attributes to roles. Both support SP- and IdP-initiated flows, tested against Okta, ADFS, Azure AD, OneLogin, and Ping Identity.

The model extends to end users. Application reverse proxy lets Versa sit as an IdP broker in front of SaaS applications (Box, Dropbox, Salesforce, Office) and private web, SSH, or RDP applications: the real IdP authenticates the user, hands Versa a SAML assertion, and only then does the reverse proxy grant access – enforcing ZTNA, SWG, CASB, and DLP in the same path.

Frequently asked questions

What is the difference between an IdP and a service provider (SP)?

The IdP authenticates the user and issues a signed assertion; the SP is the application the user is trying to reach, and it trusts that assertion instead of managing the password itself. Director and Concerto act as service providers when configured for SSO.

What is the difference between SAML and OpenID Connect?

SAML is an older XML-based standard exchanging signed assertions between an IdP and an SP, common in enterprise SSO. OpenID Connect, built on OAuth 2.0, uses JSON web tokens instead and fits API-first and modern web integrations better. Director and Concerto support both standards.

What is the difference between SP-initiated and IdP-initiated SSO?

SP-initiated SSO starts when a user clicks a login link on the application, redirecting them to the IdP for authentication. IdP-initiated SSO starts at the IdP’s own portal, redirecting an already-authenticated user directly into the application – no separate login click required.

Can an organization use more than one IdP?

Yes. Director supports multiple SSO connectors, and application reverse proxy can front multiple SaaS and private applications, each pointing at a different IdP or authentication profile – letting one organization mix cloud and on-premises identity providers, wherever it makes sense.

Does an IdP replace local user accounts?

Not necessarily. Director and Concerto support IdP-based and local authentication side by side, so administrators can keep a local emergency-access account while most users authenticate through SSO – a fallback if the IdP itself ever becomes unreachable, unresponsive, or misconfigured.

More on IdP

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about IdP, these are worth looking at next.