Keep this bookmarked
This is a reference page. Come back to it when you are evaluating an organization's IdP during an audit, comparing vendors during a security assessment, or writing a recommendation for which IdP to adopt. The tables below cover technical capabilities and GRC-relevant features side by side.
Core capability comparison
| Capability | Okta | Microsoft Entra ID | Auth0 | Google Workspace |
|---|---|---|---|---|
| SSO protocols | SAML 2.0, OIDC, WS-Fed | SAML 2.0, OIDC, WS-Fed | SAML 2.0, OIDC | SAML 2.0, OIDC |
| MFA options | Okta Verify (push), TOTP, FIDO2/WebAuthn, SMS, Email | Microsoft Authenticator (push), TOTP, FIDO2, SMS, Passkeys | Guardian (push), TOTP, SMS, Email, WebAuthn | Google Prompt (push), TOTP, FIDO2 security keys, SMS |
| Phishing-resistant MFA | FIDO2/WebAuthn, Okta FastPass | FIDO2, Passkeys, Certificate-based auth | WebAuthn | FIDO2 security keys |
| Directory features | Universal Directory: custom attributes, groups, linked objects | Entra ID directory + on-prem AD sync via Entra Connect, dynamic groups | Per-tenant user store, custom metadata, organizations | Google Directory: users, groups, OUs, custom attributes |
| Nested groups | Yes (via group rules) | Yes (native and dynamic) | No | Yes (via OUs and group nesting) |
| SCIM provisioning | Yes, 200+ SCIM integrations | Yes, Entra ID provisioning service | Yes (limited connectors) | Yes (Google-native services, limited third-party SCIM) |
| Auto-provisioning | Lifecycle Management with workflows | Entra ID lifecycle workflows, dynamic groups | Pre/post login Actions for JIT provisioning | Auto-provisioning to Google services, SAML JIT for third-party |
| Conditional/adaptive access | Authentication policies, Okta FastPass, device trust, network zones | Conditional Access policies: user/group, device compliance, location, sign-in risk | Adaptive MFA, Actions for custom logic, bot detection | Context-Aware Access: device posture, IP, geo, OS |
| API access management | Okta API Access Management (OAuth 2.0 authorization server) | Entra ID app registrations, Microsoft Identity Platform | Core product: API authentication, machine-to-machine tokens, RBAC | Limited (Google Cloud IAM for GCP APIs) |
| Pricing model | Per user/month, tiered (SSO, MFA, Lifecycle, Governance) | Free tier with M365; Premium P1 and P2 tiers for Conditional Access and Governance | Free tier (7,500 MAU); paid tiers per MAU | Bundled with Google Workspace per-user pricing |
| Best suited for | Cloud-native companies needing a dedicated IdP | Enterprises on Microsoft 365 and Azure | Product teams building customer-facing authentication | Organizations using Google Workspace and GCP |
Reading the table
A few notes to keep in mind when using this matrix:
- WS-Fed is a legacy protocol you will encounter at Microsoft-centric enterprises. SAML and OIDC cover the vast majority of modern integrations.
- Phishing-resistant MFA matters more each year. FIDO2 security keys and passkeys eliminate the credential phishing risk entirely. If an organization is pursuing NIST 800-63 AAL3 or zero-trust architecture, this row is the one to check first.
- SCIM provisioning quality varies. "Yes" in this table means the IdP supports the protocol — the actual number of applications with production-quality SCIM connectors differs significantly. Okta and Entra ID lead here; Auth0 and Google Workspace require more custom work.
- Pricing is the most volatile row. Tiers, features, and per-user costs change frequently. Verify current pricing during any vendor evaluation.
GRC-relevant features
This table focuses on the features a GRC Engineer evaluates during audits, vendor assessments, and compliance program design.
| GRC Feature | Okta | Microsoft Entra ID | Auth0 | Google Workspace |
|---|---|---|---|---|
| Audit log retention | System Log: 90 days (standard), longer with log streaming to SIEM | Sign-in logs: 30 days (free), 30 days (P1/P2); longer via Diagnostic Settings export to Log Analytics | Tenant logs: 2-30 days depending on plan; longer via Log Streaming | Admin audit log: 6 months in console; longer via BigQuery export |
| Compliance certifications (vendor) | SOC 2 Type II, ISO 27001, ISO 27018, FedRAMP, HIPAA BAA | SOC 2 Type II, ISO 27001, ISO 27018, FedRAMP High, HIPAA BAA, multiple others | SOC 2 Type II, ISO 27001, HIPAA BAA | SOC 2 Type II, ISO 27001, ISO 27018, FedRAMP, HIPAA BAA |
| User lifecycle automation | Full lifecycle management: joiner, mover, leaver workflows | Lifecycle workflows (P2), dynamic group membership, HR-driven provisioning (Workday, SAP) | Limited: Actions for custom logic, no native HR integration | Basic: auto-provisioning for Google services, manual for third-party |
| Access review/certification | Okta Identity Governance: scheduled access reviews, certification campaigns | Entra ID Governance (P2): access reviews for groups, apps, and roles | Not native (custom implementation via Management API) | Not native (requires third-party tooling) |
| Admin role granularity | 30+ built-in admin roles, custom admin roles | 80+ built-in roles, custom roles, Privileged Identity Management (PIM) for JIT admin access | Role-based access in Dashboard, limited granularity | 15+ admin roles, custom admin roles via Admin Console |
When to recommend which IdP
This is not a product endorsement — it is a practical guide for understanding which IdP fits which organizational context. During audits and vendor assessments, you need to evaluate whether the organization's IdP choice is reasonable for their environment.
Recommend evaluating Okta when: the organization is cloud-native with no existing Microsoft or Google ecosystem dependency, needs a large SSO app catalog with minimal integration work, or requires dedicated identity governance features (access reviews, certification campaigns) without a Microsoft E5 license.
Recommend evaluating Entra ID when: the organization already uses Microsoft 365, needs deep Conditional Access policies tied to device compliance (Intune), operates in Azure, or requires FedRAMP High authorization.
Recommend evaluating Auth0 when: the question is about customer-facing authentication (how do your product's users log in?), the engineering team needs flexible authentication flows with custom logic, or the use case involves CIAM rather than workforce identity.
Recommend evaluating Google Workspace when: the organization already uses Google Workspace for email and collaboration, operates primarily in GCP, or is a smaller organization that wants identity bundled with productivity tools without a separate IdP vendor.
Common multi-IdP patterns
Many organizations use more than one IdP. These are the patterns you will encounter:
- Okta + Auth0: Okta for workforce identity (employee SSO), Auth0 for customer identity (product login). Common at SaaS companies. Both are now under the Okta umbrella but remain separate products.
- Entra ID + Okta: Entra ID for Microsoft 365 and Azure access, Okta as the primary SSO gateway for non-Microsoft applications. Common at enterprises that adopted M365 first and added Okta for broader app coverage.
- Google Workspace + Okta: Google for email and collaboration, Okta for SSO to everything else. Common at companies that started on Google Workspace and outgrew its SSO capabilities.
When you encounter a multi-IdP environment, the key audit question is: which IdP is authoritative for offboarding? If disabling a user in Okta does not disable their Entra ID account (or vice versa), there is a gap in the deprovisioning process. Document it.
Quick reference: evidence to pull from each IdP
During audits, you will be asked to produce evidence from the IdP repeatedly. This table maps the five most common evidence requests to the exact location in each IdP's admin interface.
| Evidence Request | Okta | Entra ID | Auth0 | Google Workspace |
|---|---|---|---|---|
| Complete user list with status | Admin > Directory > People (export CSV) | Users > All users > Download users | Management API: GET /api/v2/users | Admin Console > Users (export CSV) |
| MFA enrollment report | Reports > MFA enrollment | Entra ID > Security > Authentication methods > User registration details | Management API: GET /api/v2/users (filter by multifactor) | Admin Console > Reporting > User reports > Security |
| Application assignments | Applications > Applications (per-app user list) | Enterprise applications > Users and groups | Dashboard > Applications > Users | Admin Console > Apps > SAML apps |
| Authentication policy config | Security > Authentication policies | Security > Conditional Access > Policies | Dashboard > Auth Pipeline > Rules/Actions | Security > Authentication > SSO settings |
| Audit log export | Reports > System Log (or Okta System Log API) | Entra ID > Audit logs / Sign-in logs | Dashboard > Logs (or Management API) | Admin Console > Reporting > Audit log |
Tips for evidence collection
Automate where possible. Every IdP listed above has an API. Instead of manually exporting CSVs each quarter, build a script that pulls the user list, MFA enrollment, and application assignments on a schedule and stores them in your evidence repository with timestamps. This is the GRC Engineering approach — continuous evidence collection, not quarterly fire drills.
Timestamp everything. Auditors need to see that controls were operating throughout the audit period, not just at the moment you pulled the export. A user list from today proves today's state. A series of monthly user list snapshots proves the control was operating all year.
Know the retention limits. Audit log retention is the most common gap. If your IdP only retains logs for 30 days and your audit period is 12 months, you have a 10-month evidence gap. Set up log streaming to a SIEM or long-term storage on day one.
Export configurations, not just screenshots. JSON or CSV exports are more trustworthy evidence than screenshots. They are harder to fabricate, easier to compare across time periods, and machine-readable for automated compliance checks. Use policy exports over screenshots whenever the IdP supports them.
IdP evaluation checklist for vendor assessments
When assessing a vendor's identity practices — or evaluating your own organization's IdP — use this checklist. Each item maps to common SOC 2 and ISO 27001 controls.
| Check | What you are verifying | Framework mapping |
|---|---|---|
| Centralized IdP in use | All users authenticate through a single identity provider | SOC 2 CC6.1, ISO 27001 A.9.2 |
| SSO enforced for all apps | No applications allow local username/password when SSO is available | SOC 2 CC6.1, ISO 27001 A.9.4 |
| MFA enforced | All users are required to use a second factor, with no permanent exceptions | SOC 2 CC6.1, NIST 800-53 IA-2 |
| SCIM or automated provisioning | User accounts are created and deactivated automatically | SOC 2 CC6.2, ISO 27001 A.9.2.6 |
| Offboarding SLA defined | Access is revoked within a documented timeframe (e.g., 24 hours) after termination | SOC 2 CC6.2, ISO 27001 A.9.2.6 |
| Audit logs retained | Authentication and admin logs are retained for the full audit period | SOC 2 CC7.2, ISO 27001 A.12.4 |
| Access reviews conducted | Periodic reviews of who has access to what, with documented outcomes | SOC 2 CC6.3, ISO 27001 A.9.2.5 |
| Admin access restricted | IdP admin roles are limited to a small number of named individuals | SOC 2 CC6.1, ISO 27001 A.9.2.3 |