Identity Provider Fundamentals

Every compliance framework you will work with has controls around access management. SOC 2 CC6.1 covers logical access. ISO 27001 A.9 covers access control. NIST 800-53 has an entire family (AC) dedicated to it. All of these controls share a common assumption: there is a centralized system that knows who your users are, authenticates them, and controls what they can access.

That system is the Identity Provider.

This lesson covers what an IdP does, why centralization matters for compliance, and the four major IdPs a GRC Engineer encounters in the field. By the end, you will be able to evaluate whether an organization's identity architecture meets baseline compliance requirements.

What an Identity Provider centralizes

An Identity Provider is a service that manages user identities and authentication for an organization. It is the single source of truth for "who works here, and how do they prove they are who they say they are."

A properly configured IdP centralizes five functions:

User directory. The authoritative list of every employee, contractor, and service account. Names, email addresses, department, manager, employment status, group memberships. When an auditor asks "how many active users have access to your systems," the answer comes from here.

Authentication. The login process itself. Username and password, passwordless, certificate-based, whatever the organization uses. The IdP is the front door. Applications do not maintain their own login systems — they delegate authentication to the IdP.

Single Sign-On (SSO). One authentication event grants access to multiple applications. A user logs into the IdP once and can access Slack, GitHub, AWS, Jira, and every other connected application without logging in again. The protocols that make this work — SAML 2.0, OpenID Connect, WS-Federation — are covered in a later lesson. For now, understand that SSO is a function of the IdP.

MFA enforcement. Multi-factor authentication policies defined once and applied everywhere. The IdP decides when a second factor is required: always, only for sensitive apps, only from untrusted networks. This is a centralized policy, not a per-application setting.

Lifecycle management. Onboarding and offboarding. When a new employee starts, the IdP provisions their accounts across connected applications. When someone leaves, disabling their IdP account immediately revokes access to everything connected to it. The speed of that revocation — the offboarding SLA — is one of the most scrutinized metrics in a SOC 2 audit.

┌──────────────────────┐
                       │   Identity Provider   │
                       │                      │
┌──────────┐           │  ┌────────────────┐  │           ┌──────────────┐
│          │           │  │  User Directory │  │           │   Slack      │
│  Users   │──────────▶│  ├────────────────┤  │──────────▶│   GitHub     │
│          │  Authenticate │  SSO           │  │  Federated│   AWS        │
│ Employee │           │  ├────────────────┤  │  Access   │   Jira       │
│ Contractor│          │  │  MFA Policies  │  │           │   Salesforce │
│ Admin    │           │  ├────────────────┤  │           │   GCP        │
│          │           │  │  Lifecycle     │  │           │   Datadog    │
└──────────┘           │  └────────────────┘  │           └──────────────┘
                       └──────────────────────┘

One login. One place to disable access. One audit log.

Why centralization matters for compliance

Without a centralized IdP, every application maintains its own user database and its own login system. Slack has a user list. GitHub has a user list. AWS has IAM users. Jira has a user list. When someone leaves the company, IT has to remember every application, log into each one, and disable the account manually.

This creates three compliance problems that auditors flag immediately:

Orphaned accounts. When offboarding is manual and per-application, accounts get missed. The employee's Okta account is disabled, but their standalone GitHub account with a personal password still has write access to production repositories. Six months later, an auditor finds it. That is a SOC 2 CC6.2 finding.

Inconsistent authentication. Without SSO, some applications enforce MFA and some do not. The auditor asks: "Is MFA enforced for all access to production systems?" The honest answer is "mostly" — which is not a passing answer.

No single audit trail. If five applications handle their own authentication, the audit log for "who logged in when" is spread across five different systems with five different formats. Correlating access events becomes a manual investigation instead of a single query.

A centralized IdP solves all three. One user directory means one place to disable accounts. SSO means one authentication policy applied everywhere. One IdP means one audit log for every authentication event across the organization.

The four IdPs you will encounter

Most organizations use one of four identity providers. Each has different strengths, and you will see all of them across different clients, employers, and vendor assessments.

Okta

Okta is a standalone Identity Provider — identity is the entire product, not a feature bundled with something else. It has the largest pre-built application integration catalog (over 7,000 apps), which means connecting a new SaaS tool to SSO usually takes minutes rather than custom configuration.

Okta's Workforce Identity Cloud covers SSO, MFA (Okta Verify push, TOTP, FIDO2/WebAuthn, SMS), Universal Directory for user management, and Lifecycle Management for automated provisioning and deprovisioning via SCIM. Okta also offers Advanced Server Access for SSH and RDP access management, and Identity Governance for access reviews and certification campaigns.

GRC relevance: Okta is the IdP you will encounter most often at cloud-native companies and SaaS startups. Its system log provides a comprehensive audit trail. When pulling compliance evidence, you will export Okta system logs, authentication policy configurations, MFA enrollment reports, and application assignment lists. Okta holds SOC 2 Type II, ISO 27001, and FedRAMP certifications.

Microsoft Entra ID (formerly Azure AD)

Entra ID is bundled with Microsoft 365. Any organization that uses Outlook, Teams, or SharePoint already has an Entra ID tenant — which means it is the most widely deployed IdP in the world by user count. It is deeply integrated with the Microsoft and Azure ecosystem.

Entra ID's defining feature for GRC is Conditional Access. Conditional Access policies evaluate signals at authentication time — user role, device compliance status, location, sign-in risk score — and make real-time access decisions: allow, block, or require MFA. These policies are the primary control mechanism for organizations using Microsoft infrastructure.

GRC relevance: you will encounter Entra ID at enterprises and any company that runs on Microsoft 365. During audits, you pull Conditional Access policy exports, sign-in logs, MFA registration reports, and Entra ID audit logs. Entra ID supports SAML, OIDC, and WS-Federation. It holds SOC 2 Type II, ISO 27001, and FedRAMP High certifications.

Auth0 (by Okta)

Auth0 is a developer-focused identity platform, now owned by Okta. While Okta targets workforce identity (employees accessing internal tools), Auth0 targets customer identity and access management (CIAM) — the login experience for your product's end users.

Auth0 provides flexible authentication flows, social login integration, custom Actions (serverless functions that run during authentication), and extensive API-first management. Organizations use Auth0 when their product needs a login system that goes beyond what a generic IdP offers — custom branding, progressive profiling, bot detection, passwordless auth for customers.

GRC relevance: Auth0 appears in vendor assessments when you are evaluating how a SaaS product authenticates its users. If your company builds a product, Auth0 might be how your customers log in. During audits, the relevant evidence is Auth0 tenant configuration, connection settings, MFA policies for customer accounts, and audit logs from the Auth0 Dashboard. Auth0 holds SOC 2 Type II and ISO 27001 certifications.

Google Workspace

Google Workspace includes a built-in directory and identity provider. Organizations using Gmail, Google Drive, and Google Meet authenticate through Google's identity infrastructure. It integrates tightly with Google Cloud Platform (GCP), making it the natural IdP for Google-centric environments.

Google Workspace supports SSO via SAML and OIDC, MFA enforcement (TOTP, Google Prompt, FIDO2 security keys), and Context-Aware Access — Google's equivalent of Conditional Access, which evaluates device posture, network, and geographic signals before granting access to Google services and configured SAML apps.

GRC relevance: you will see Google Workspace at startups, media companies, and education institutions. During audits, you pull the Admin Console audit log, SSO configuration, MFA enforcement reports, and Context-Aware Access policy exports. Google Workspace holds SOC 2 Type II, ISO 27001, and FedRAMP certifications.

Comparison at a glance

IdP centralization and compliance frameworks

The requirement for centralized identity management is not just a best practice — it is explicitly or implicitly required by every major framework.

SOC 2 CC6.1 requires logical access security over protected information assets. A centralized IdP with SSO enforcement is the most direct way to satisfy this — it proves that every access event goes through a single, controlled authentication system.

SOC 2 CC6.2 requires that access is revoked when no longer needed. An IdP with automated deprovisioning provides the evidence: a single disable action, timestamped in the IdP audit log, that simultaneously revoked access to all connected applications.

ISO 27001 A.9.2 covers user access management, including registration, deregistration, and access review. A centralized directory is the mechanism for all three.

NIST 800-53 AC-2 requires account management including creation, activation, modification, disabling, and removal. An IdP with lifecycle management addresses every sub-requirement.

The pattern is consistent across frameworks: centralize identity, enforce authentication consistently, automate provisioning and deprovisioning, and maintain an audit trail. The specific IdP you use matters less than whether you use one at all and whether all applications are connected to it.

Common IdP anti-patterns

Knowing what good looks like is only half the job. You also need to recognize the patterns that create compliance risk. These are the IdP anti-patterns you will encounter most often.

Shadow IT bypassing SSO. Teams adopt SaaS tools by signing up with a corporate email address and a personal password, bypassing the IdP entirely. The tool is never connected to SSO. The IdP has no record that the tool exists, so offboarding cannot revoke access. During audits, you discover these by comparing the IdP's application list against a SaaS management tool like Zylo, Productiv, or Torii — or by reviewing SSO exemption requests.

SSO without SCIM. The application is connected for authentication (SSO works), but provisioning and deprovisioning are manual. When someone leaves, their IdP session is revoked, but their local account in the application persists with a still-valid API key or a password set before SSO was enforced. The fix is enabling SCIM where supported and manually auditing applications that do not support it.

MFA exceptions that never expire. A user reports an issue with their MFA device. IT grants a temporary MFA bypass. The bypass is never revoked. Six months later, the user is still authenticating without a second factor. During audits, pull the list of active MFA exceptions and verify each has a documented justification and an expiration date.

No IdP for infrastructure. SSO covers SaaS applications, but engineers access AWS, GCP, or Azure through standalone IAM users with long-lived credentials. The IdP controls access to Slack and Jira but not to production infrastructure. This is the highest-risk gap — production access with no centralized authentication, no session management, and no MFA enforcement from the IdP.

What comes next

This lesson covered what an IdP does and why centralization is the foundation of identity compliance. The next lesson walks through IdP architecture visually — how the directory, SSO flow, MFA enforcement, and provisioning work together in a real deployment. After that, a reference comparison matrix gives you a detailed, bookmarkable breakdown of capabilities across all four IdPs.