Get Started Contact Sales
Glossary

IdP (Identity Provider)

An identity provider (IdP) is a service that creates, stores and verifies digital identities, then shares that verified identity with applications and networks. It underpins single sign-on and is the authority a captive portal or RADIUS server checks when a user logs in.
Last updated: October 9, 2026

What an identity provider is

An identity provider (IdP) is the system that holds and verifies who a user is. When a person signs in, the IdP checks their credentials and then vouches for their identity to the applications and services they are trying to reach. Common examples include Microsoft Entra ID (formerly Azure AD), Okta, Google and Ping.
The IdP is the single source of truth for identity. Instead of every app and network keeping its own usernames and passwords, they all trust the IdP to authenticate the user.

What an IdP does

At its core an IdP authenticates users and issues a trusted assertion of their identity. It typically also manages the lifecycle of accounts — creating them, updating roles and group membership, and disabling them when someone leaves. It also enforces controls such as multi-factor authentication.
Because it centralizes identity, the IdP is where security policy like MFA, conditional access and password rules is applied once and inherited everywhere.

How IdPs work: SAML, OIDC and OAuth

IdPs communicate with applications using federation standards. SAML (Security Assertion Markup Language) and OpenID Connect (OIDC, built on OAuth 2.0) are the most common. The application redirects the user to the IdP, the IdP authenticates them and returns a signed token or assertion, and the application trusts it.
This redirect-and-assert pattern is what powers single sign-on (SSO): authenticate once with the IdP, then reach many services without logging in again.

IdPs and WiFi access

Identity providers play two roles in network access. On a captive portal, an IdP enables SSO sign-on. A guest or employee logs in with their existing corporate or social account instead of creating a new one. For secure enterprise WiFi, the IdP sits behind the RADIUS server: when a device authenticates with 802.1X, RADIUS checks the user against the IdP or directory.
Either way, the IdP means WiFi access is governed by the same identities and policies as the rest of the organization's systems.

IdP vs RADIUS

An IdP and a RADIUS server are often confused because both deal with authentication. The difference is the layer. RADIUS is the protocol that network devices use to ask for an access decision; the IdP is the authority that actually knows the user and their credentials.
In a typical secure WiFi setup they work together: the RADIUS server receives the 802.1X request and validates the user against the IdP or directory behind it.

Benefits of using an IdP

Centralizing identity in an IdP brings several advantages:

  • Single sign-on, so users authenticate once across many services.
  • Consistent security policy such as MFA and conditional access, applied centrally.
  • Faster onboarding and offboarding, since access follows one account.
  • A clear audit trail of who accessed what and when.

IdP and Zero Trust

Identity is the foundation of Zero Trust, and the IdP is where that identity lives. Zero Trust assumes nothing is trusted by default and verifies every access request. That only works if there is a reliable, central authority on who each user is. The IdP provides that, along with the signals — group membership, device, location, risk — that conditional access policies act on.
This is why modern security architectures put so much weight on the IdP. Multi-factor authentication, conditional access and single sign-on are all enforced there, so strengthening the IdP strengthens access to everything behind it, including the network.

Federation and the modern identity stack

Federation is what lets one IdP serve many systems, including some outside the organization. Using SAML or OpenID Connect, an application trusts the IdP's signed assertion rather than holding its own passwords. This is how a user signs in once and reaches dozens of cloud apps. It is also how a guest can use a social or corporate account on a captive portal instead of creating a new one.
For WiFi specifically, federation means network access can reuse the same identities and policies as the rest of the business. When someone leaves and their IdP account is disabled, their network access disappears with it — there is no separate WiFi credential to remember to revoke. That single source of truth is the practical payoff of building access around an identity provider.

IdP with Cloud4Wi

Cloud4Wi integrates with identity providers so organizations can use their existing identities for WiFi. Guests and employees can sign on to the captive portal with SSO, and secure enterprise WiFi can authenticate against the IdP through cloud RADIUS and 802.1X. That keeps WiFi access aligned with the same identity, MFA and lifecycle policies the organization already runs, without duplicating user accounts.
As organizations consolidate around cloud apps and remote work, the identity provider has quietly become the most important security control they run. It is the single front door to everything, including the network. Investing in a strong IdP — with MFA, conditional access and clean lifecycle management — pays off across every system. Treating WiFi as just another application that trusts that same IdP keeps network access aligned with the organization's overall identity strategy rather than sitting outside it. The payoff is a network whose access decisions are only ever as current as the identities behind them — which, with a well-run IdP, means they update instantly.

— FAQ

Frequently asked questions

Everything you need to know about IdP and how it works.

They operate at different layers. RADIUS is the protocol that network devices use to request an access decision when a device authenticates with 802.1X. The identity provider is the authority that actually knows the user and their credentials. In practice the RADIUS server receives the request and validates the user against the IdP or directory behind it.

When a user reaches an application, it redirects them to the identity provider, which authenticates them and returns a signed token or assertion using standards like SAML or OIDC. The application trusts that assertion. Because the IdP holds the session, the user can then reach other connected services without logging in again, which is single sign-on.

On a captive portal, an IdP lets users sign on with an existing account instead of creating a new one — corporate SSO for employees or a social login for guests. The portal redirects to the IdP, which authenticates the user and returns their verified identity, so WiFi access uses the same identities as other systems.

IdPs commonly use SAML and OpenID Connect, which is built on OAuth 2.0. These federation standards let an application trust the IdP's signed assertion of a user's identity without handling passwords itself. They matter because they enable single sign-on, reduce password sprawl, and let security controls like MFA be enforced once at the IdP.

Centralizing identity gives single sign-on, consistent security policy such as MFA and conditional access, and faster onboarding and offboarding since access follows one account. It also produces a single audit trail of who accessed what. Managing separate logins per system creates password sprawl, inconsistent policy, and gaps when someone leaves the organization.

Ready to reimagine your WiFi?

Spin up your 30-day free trial in minutes, or book time with our team of WiFi experts to scope an enterprise rollout.

  • SOC 2 certified
  • No credit card required
  • GDPR & global compliance
  • No rip-and-replace