Identity Platforms & IdP Architecture
The Centralized IdP pattern as a system, plus Auth0, Keycloak, Okta, and AWS Cognito as the implementations you'd actually pick. Cost curves, multi-tenancy models, and the architectural lock-in nobody warns you about.
Artifact 3 of 3Platforms / ArchitecturePE Depth
As of 2026-06-05. Reflects post-Okta-acquisition Auth0 pricing ($0.07/MAU), Keycloak 26, AWS Cognito Gen 2, and the cost crossover that drives Keycloak adoption above 10K MAU.
PE Verdict
The IdP is the most important single architectural decision in your auth stack, because changing it is a 6-12 month project with active migration risk. Pick Auth0 for fastest time-to-market under 10K MAU. Pick Keycloak when cost crosses $50K/year (typically 50K+ MAU) and you have ops capacity. Pick Okta for workforce SSO where deep enterprise integrations matter. Cognito is the right answer only when you're already deeply locked into AWS and don't need a polished admin UX.
Best default choices
Centralized IdPDefault architecture when multiple apps need one policy, lifecycle, audit, and federation authority
Auth0Default for fastest CIAM delivery under roughly 10K MAU or when polished hosted login matters most
KeycloakDefault when per-user SaaS cost, sovereignty, or deep self-hosted control outweigh operational burden
OktaDefault for enterprise workforce IAM, app catalog depth, lifecycle management, and governance integrations
AWS CognitoDefault for AWS-native apps that need low-cost user pools and IAM integration more than polished admin UX
Compare
1. Trade-Offs
Centralized IdP (Architectural Pattern) The pattern, not a product
Use the centralized IdP pattern when identity policy, lifecycle, MFA, federation, and audit need one durable control plane across many applications.
| Trade-Off | What You Gain | What You Give Up | When It Bites You | PE Nuance |
|---|---|---|---|---|
| One identity authority for all apps | Single source of truth for user identity, policy, MFA enforcement, deprovisioning | IdP becomes the highest-blast-radius SPOF in the architecture | IdP has a 4-hour outage at 9am Monday, the entire company can't work, every app looks broken simultaneously | Multi-region active-active IdP is table stakes for serious deployments. Most teams discover the SPOF concern after their first IdP outage; treat as non-optional from day one. |
| Centralized policy + governance | MFA, password rules, session timeout, audit logging enforced once | Policy changes affect every connected app uniformly — risk of unintended broad impact | Tighten password policy, 30% of users fail next login, helpdesk drowns, exec backs off the change mid-rollout | Stage policy changes via canary tenants / canary apps before broad rollout. Treat IdP policy changes with the same care as infrastructure changes — they touch everything. |
| Federation in + federation out | Accept external IdPs (consumer social, B2B enterprise) and act as IdP to internal apps | Trust chain complexity — compromise of any upstream IdP propagates | B2B customer's IdP is breached, attacker pivots through the federation into your tenants, your SOC has no visibility into the source | Authn assurance level (AAL) in OIDC acr/amr claims should be passed through and enforced. "We support SSO" without specifying AAL is meaningless contractually and operationally. |
| Identity lifecycle (provisioning / deprovisioning) | SCIM-driven user lifecycle propagates across all connected apps | Deprovisioning lag — sessions outlive IdP user disable until token TTL expires | Engineer terminated 9am, JWTs valid 8h, retains GitHub + Slack + AWS Console access for the workday | Short TTL (15-30min) + active session revocation (CAE, SSF) + back-channel logout is the only complete answer. Termination playbook should explicitly cover this gap. |
| Per-app authentication policy via acr | High-trust ops require higher AAL; reuses one IdP for varied risk | Per-app policy authoring is non-trivial; consistency across apps is hard | One app prompts MFA for "edit settings", another doesn't prompt for "transfer funds", attacker uses captured session to exfiltrate via the lax one | Define authentication context classes once (low/med/high assurance), enforce via centralized policy (the IdP), not in apps. Cedar/OPA can read acr and uniformly enforce. |
| Audit centralization | All authn events flow to one log; easier SIEM correlation | Per-app authz events are still distributed; audit story is split | Auditor asks "who modified prod config Tuesday", IdP says "Alice logged in 9am", that's all you have without app logs | IdP gives authn events. App-level authz logs are still required. SIEM correlation across both is the win — but the IdP alone isn't a complete audit story. |
| One auth UI to maintain | Universal login experience, brand consistency, one place to fix bugs | Customization across diverse app needs is constrained by IdP capabilities | Marketing wants a custom signup flow per product, IdP supports it but with template limits, dev team builds awkward workarounds | If your IdP doesn't support hosted-vs-embedded flows flexibly, you'll fight the IdP. Auth0 Universal Login + custom domains is the polished pattern; Keycloak/Cognito theming is workable but less refined. |
| Vendor / platform lock-in | Deep integrations (Actions, Workflows, custom rules) accelerate delivery | Migration cost grows quadratically with feature usage — custom logic doesn't port | Auth0 contract renewal: 3x price increase, you discover the 47 Actions and 12 Rules that comprise core business logic are not portable, you renew | Vendor lock-in is real. Limit "custom logic in IdP" to authentication-specific concerns. Move business logic out to your services where it's portable. Treat the IdP as a protocol implementation, not a platform. |
Auth0 CIAM platform, acquired by Okta 2021, $0.07/MAU paid tier
Best for fast CIAM delivery, polished hosted login, social login, and B2B Organizations while accepting per-MAU cost growth and Actions lock-in.
| Trade-Off | What You Gain | What You Give Up | When It Bites You | PE Nuance |
|---|---|---|---|---|
| Fastest time-to-market for consumer-facing auth | Universal Login + social IdPs + MFA + passwordless out of the box; days not weeks to ship | Polished UX comes with developer convention you must follow | You build a startup MVP with Auth0, hit 100K MAU, finance asks why monthly bill jumped 5x | For startups under 10K MAU, Auth0 is the fastest path. The trap is that quick wins encode lock-in. Architect for IdP-swap from day one (Auth0 today, Keycloak at scale). |
| Per-MAU pricing post-Okta acquisition | Predictable per-active-user cost at low scale; free tier 7,500 MAU | Costs scale linearly with users; at 100K MAU expect $7K-15K/month base + enterprise add-ons | Hockey-stick growth pushes you from 50K to 500K MAU in a year, bill goes from $30K/mo to $300K+/mo | Pricing reset post Okta acquisition was aggressive — $0.07/MAU is real, enterprise add-ons (SAML, SCIM, advanced MFA) push it higher. Validate cost crossover with Keycloak before signing multi-year contracts. |
| Actions and Hooks for custom auth logic | JavaScript runtime in the auth flow — enrich tokens, validate, conditional MFA, custom claims | Custom logic locked into Auth0's runtime; migration to another IdP means rewriting all Actions | You have 47 Actions running business logic; quoting a migration to Keycloak, 6-12 month timeline, you stay with Auth0 reluctantly | Actions are the lock-in mechanism. Limit them to auth-specific concerns (claim enrichment, MFA decisions). Business logic belongs in your services, not in the IdP runtime. |
| Universal Login as the auth surface | Centralized, themeable, polished, supports all flows; security patches at the IdP | Embedded login (in-app credential entry) is supported but discouraged; some patterns require Universal Login | Native mobile app team wants in-app login UX, has to use ASWebAuthSession / Custom Tabs, UX dev pushes back | Universal Login is the right pattern for security (defeats credential phishing) but does limit UX flexibility. Use it. The 1-tap UX cost is worth the security gain. |
| Multi-tenant by default for B2B | "Organizations" feature for B2B multi-tenant CIAM; one tenant per customer with shared infra | Organizations is a paid feature; cross-tenant policies are tricky | Free / Essential plan ships B2C; you sign first B2B customer who wants tenant isolation, must upgrade tier | If your roadmap includes B2B SaaS within 12 months, start on a tier that supports Organizations. Retrofit is painful. |
| FedRAMP, HIPAA, ISO 27001 compliance ready | Audit-friendly out of the box; compliance documentation provided | Enterprise compliance tier pricing significantly higher than base | Sales lands a healthcare deal requiring HIPAA, you discover the BAA requires enterprise tier upgrade ($$$) | Compliance tier is necessary for regulated industries but should be planned for. Verify your specific compliance needs map to a specific Auth0 tier before committing to deals. |
| Custom domains for branded auth | auth.yourbrand.com instead of yourbrand.auth0.com; better user trust | Custom domains are a paid feature; cert management overhead | Marketing demos Universal Login at yourbrand.auth0.com, exec asks "why does it say auth0 in the URL", awkward conversation | Custom domains are required for any consumer-facing brand. Budget for it from day one; don't deploy without it for production B2C. |
| Logs and analytics retention | Built-in event logs for authn, MFA challenges, anomalies | Log retention is tier-limited (often 30 days base); long-term audit requires Log Streams to S3/SIEM | Compliance audit requires 1-year auth logs, you discover Auth0 stores 30 days, you scramble to set up Log Streams | Set up Log Streams to S3 / Datadog / Splunk on day one. Don't rely on Auth0 log retention for audit requirements; treat as ephemeral. |
Keycloak Open source (Apache 2.0), Java-based, Red Hat maintained, Keycloak 26 (2025)
Choose when open source control, data sovereignty, and per-user cost avoidance justify operating a critical Java/Postgres identity service yourself.
| Trade-Off | What You Gain | What You Give Up | When It Bites You | PE Nuance |
|---|---|---|---|---|
| Zero per-user cost (Apache 2.0) | Infrastructure cost only; saves $162K/yr vs Auth0 at 100K users, $942K/yr vs Okta | Ops cost: 3-5 hours/week of expertise to maintain; production HA non-trivial | 100K users on Keycloak with no DBA, Postgres falls over during traffic spike, no one knows how to tune it | Cost crossover with Auth0 typically at 10K-50K MAU depending on tier. Keycloak total cost includes 0.5-1 SRE FTE; budget honestly. |
| Full feature parity with commercial IdPs | OIDC, SAML, LDAP federation, social IdPs, fine-grained authz, themes, custom flows | Heavyweight Java footprint; 1-2GB RAM per node minimum | Lightweight serverless deployments are awkward; Keycloak is a long-running JVM service | Keycloak deployment story improved with Quarkus rewrite (Keycloak 17+). Boot time and memory footprint are better than the WildFly era but still heavier than Node.js alternatives like Ory Kratos. |
| Self-hosted = full data sovereignty | User data, sessions, audit logs all in your infrastructure; GDPR / sovereignty compliance easier | You own the security posture; patching, hardening, DDoS protection are your problem | CVE drops in Keycloak component, you find out via Slack, patch window is your team's responsibility | Self-hosted IdP is a high-value target. Treat with the same care as your database. Auto-patching, monitoring, intrusion detection are all on you. |
| Themeable UI via Freemarker templates | Full HTML/CSS/JS control over login pages, account console, email templates | Theme development is a learning curve; Freemarker template syntax | Marketing wants pixel-perfect brand match, theme dev takes 2 sprints, designer doesn't want to learn Freemarker | Most teams underestimate theming effort. Budget 2-4 sprints for production-quality themes. The Phasetwo / KeycloakPro theme markets exist precisely because of this. |
| SPI (Service Provider Interface) for custom extensions | Java-level extensibility for authenticators, mappers, event listeners, user storage providers | Custom SPIs are Java; not all teams have Java expertise; tightly coupled to Keycloak internals | You write a custom user storage SPI, Keycloak upgrades to next major version, your SPI breaks because internals changed | Treat SPIs as a last resort. Most needs can be met with standard features (mappers, identity brokering, hooks). Custom Java SPIs are the deepest lock-in inside an "open" IdP. |
| Multi-realm for tenancy | Realms isolate clients, users, themes per tenant; logical separation | Realms in one Keycloak share underlying DB; tenant isolation is application-level, not infra-level | Compliance review asks "is tenant A's data physically isolated from tenant B", answer is no, you scramble for an architectural justification | For strong tenant isolation, separate Keycloak deployments per tenant cluster. Realms are good for B2B logical separation; not enough for regulated tenancy. |
| Active community + commercial support options | Red Hat Keycloak (commercial), Phasetwo, KeycloakPro, JBoss EAP — multiple support vendors | Community support quality varies; production deployments need vetted advice | Production issue at 2am, GitHub issue thread, no clear answer, you reverse-engineer the source code | For production Keycloak, either staff a Java engineer with Keycloak expertise OR contract with a support vendor (Red Hat, Phasetwo). Don't go production without one or the other. |
| Database becomes the scaling bottleneck | Standard JPA/Hibernate ORM; works with Postgres, MariaDB, Oracle | Session storage at scale (millions of active sessions) requires careful DB tuning; Infinispan for cluster cache | Login throughput at 5K/sec hits Postgres connection pool ceiling, latency degrades, login times balloon | Keycloak scaling beyond 10K active sessions/sec requires real DB engineering. Migrate sessions to Infinispan (or external Redis); tune Postgres connection pools; profile. |
Okta Workforce IAM + Customer IAM (Auth0 acquired), public company since 2017
Best for workforce identity, app catalog breadth, lifecycle management, governance, adaptive access, and enterprise integration depth.
| Trade-Off | What You Gain | What You Give Up | When It Bites You | PE Nuance |
|---|---|---|---|---|
| Workforce IAM is the strongest in market | 7000+ pre-built app integrations (OIN catalog), best-in-class lifecycle management, deep AD/LDAP federation | Pricing is per-user-per-month + per-feature; Premier/Enterprise tier add-ons stack | You start with $4/user/mo, then add MFA ($), Adaptive ($), Workflows ($), SCIM ($), and 5K users cost $30K+/mo | Okta's "per user per feature" pricing model means TCO at 10K+ users frequently exceeds $1M/year. Run the calculator with realistic feature usage before committing. |
| Lifecycle Management with deep app integrations | JIT provisioning + SCIM + custom integrations for every major SaaS | Custom workflows require Okta Workflows (additional license) or Okta Workflows API | Free-tier deployment hits limit on custom user lifecycle, must upgrade tier mid-deployment | Okta Workflows is genuinely powerful for IGA-like flows but priced as a separate product. If lifecycle automation is core to your needs, factor it into initial cost. |
| Adaptive MFA with risk-based step-up | Behavior analytics, geo + device + threat intel signals, sophisticated policy engine | Adaptive MFA tier is a paid add-on; basic MFA is included but adaptive is enterprise | Basic MFA deployment, attackers bypass via MFA fatigue, you discover number matching + adaptive is an upgrade away | Okta's adaptive MFA is competitive with Microsoft Entra Conditional Access. Worth the cost for high-value workforce. For consumer (CIAM) flows, Auth0 (Okta-owned) is the typical path. |
| Enterprise sales + procurement-friendly | SOC 2, ISO 27001, FedRAMP High, HITRUST; enterprise procurement frictionless | Pricing not transparent; everything is "contact sales" | Engineering team can't get a quick price comparison; budget approval delayed because sales cycle is 4-8 weeks | Okta pricing is opaque by design. Get quotes through procurement, not engineering. Negotiate multi-year for meaningful discount. |
| 2022 Lapsus$ incident impact | Post-incident, Okta hardened policies, expanded transparency, invested in detection | Reputational hit; security teams reasonably question vendor IdPs after seeing the support-tier compromise | Internal security review post-Lapsus$ asks "are we sure Okta is hardened against support compromise", you spend two weeks on diligence | The Lapsus$ incident exposed support-tier privilege as a weak link. Use Okta's IP allowlist for admin console, hardware key requirement for admins, and FastPass passkey for users. The platform allows good security; the question is whether you've configured it. |
| Okta FastPass (proprietary passwordless) | Passkey-equivalent, device-bound, phishing-resistant; included in Workforce Identity | Okta-proprietary; not interoperable with standard passkey flows | You enable FastPass, users love it, then enterprise customer demands BYOIdP and FastPass doesn't help | FastPass is competitive with Microsoft's Authenticator-as-passkey. Native passkey support (synced passkeys) also available. Default to standard passkeys unless FastPass-specific features needed. |
| Okta Universal Directory | Unified user profile across all connected apps; rich attribute schema | Schema design upfront work; bad initial schema = future migrations | You design Universal Directory schema in week 1 without thinking through B2B tenancy, fix it 18 months later | Spend real time on Universal Directory schema before broad rollout. It's the entity model for your identity domain — get it wrong and you carry the technical debt forever. |
AWS Cognito AWS-native, user pools + identity pools, Gen 2 advanced security features 2024+
Use for AWS-native user pools, IAM credential bridging, serverless/mobile backends, and low commercial CIAM cost when admin UX trade-offs are acceptable.
| Trade-Off | What You Gain | What You Give Up | When It Bites You | PE Nuance |
|---|---|---|---|---|
| Native AWS integration | IAM role assumption via Identity Pools; API Gateway authorizers; CloudWatch logs; Cognito Sync | Best-in-class only if you're deeply in AWS; outside AWS, integrations are limited | Multi-cloud architecture requires identity propagation, Cognito's IAM-tied identity pools awkward outside AWS | Cognito is the right choice only when your apps live in AWS and need to assume AWS IAM roles. For multi-cloud or non-AWS-heavy apps, Auth0 / Keycloak give better UX with comparable cost. |
| Per-MAU pricing with generous free tier | 50K MAU free; $0.0055/MAU above that — cheapest commercial CIAM at scale | Advanced Security Features (ASF) tier is significantly more expensive; granular limits | Free tier gets you to MVP, ASF needed for adaptive auth, pricing jumps unexpectedly | Cognito's base tier is cheapest in market. ASF is comparable to Auth0 / Okta adaptive. Run cost models with realistic ASF assumptions. |
| User Pools (CIAM) + Identity Pools (federation) | Two clear primitives: pools for managed users, identity pools for IAM role assumption | Two-step learning curve; many teams confuse the two; advanced flows require both | Dev team builds with User Pools alone, discovers they need IAM role assumption mid-project, refactors auth flow | Understand the User Pool vs Identity Pool distinction before architecting. User Pool = users + authn. Identity Pool = AWS IAM federation. Pair them for mobile-to-AWS-resource flows. |
| Lambda triggers for custom auth logic | Pre-signup, post-confirmation, pre-token-generation, custom auth challenge — extensibility points | Latency adds 100-500ms per trigger; debugging Lambda triggers in auth flow is painful | Custom auth challenge Lambda has a bug, every login fails, you debug Lambda logs while users are locked out | Keep Lambda triggers fast and idempotent. If you have 4+ triggers in a flow, the latency stacks visibly. Consider whether the IdP is the right place for the logic. |
| Admin UX is barebones | Console works; CloudFormation / CDK for IaC; everything is API-driven | No polished admin UI like Auth0 Universal Login or Okta Admin Console | Customer support team needs to look up a user, reset their password — Cognito Console is clunky, takes longer per ticket | Cognito admin UX is the consistent operator complaint. If your support team is the operator, factor in custom admin UI cost. Auth0 / Okta admin consoles are noticeably better. |
| Advanced Security Features (Gen 2) | Adaptive auth, compromised credential check, IP-based blocks; close to Auth0/Okta adaptive | ASF is significantly more expensive than base; not as sophisticated as Okta Adaptive | Adaptive auth enabled, false positives block legitimate users, ML model tuning options are limited | Cognito ASF improved substantially in 2024-2025 but still trails Okta and Microsoft Entra in policy expressiveness. Verify against your specific risk requirements. |
| Hosted UI for OAuth flows | Drop-in OAuth 2.0 + OIDC compliant login UI; customizable via CSS | Hosted UI is limited in flexibility vs Auth0 Universal Login; advanced flows require custom UI | Hosted UI doesn't support a specific flow you need, you build custom UI, lose the security benefit of hosted | Hosted UI is good for standard OIDC. If your auth flows are non-standard (multi-step, custom challenges), expect to build custom UI with Cognito SDK calls. |
| Limited B2B / multi-tenant story | App clients per tenant; user pools per tenant pattern works | No native "Organizations" concept; B2B multi-tenant requires architectural patterns layered on | B2B sales needs per-tenant SSO config, you build it with one user pool per customer, hit Cognito pool limits at 200 customers | If your business is B2B SaaS, evaluate Auth0 Organizations or AWS Cognito + custom multi-tenant layer. Native Cognito multi-tenancy is workable but more architectural lift. |
2. Use Cases
Centralized IdP Pattern — Use Cases
Use the centralized IdP pattern when identity policy, lifecycle, MFA, federation, and audit need one durable control plane across many applications.
| Use Case | Company / Scenario | Driving Property | Scale Dimension | Why Not Alternative |
|---|---|---|---|---|
| Workforce SSO across SaaS sprawl | Any 200+ person company with 50+ SaaS apps | One credential, MFA enforced once, deprovisioning at offboarding hits all apps | 10K-500K employees, 200+ SaaS apps each | Per-app local accounts: N login experiences, N password resets, manual offboarding per app |
| Consumer CIAM at scale | Spotify, Notion, Reddit — millions of consumer accounts with social federation | Centralized policy + audit + recovery; supports social IdPs uniformly | 50M-1B consumer accounts at consumer platforms | Per-product local accounts can't unify experience or audit across product portfolio |
| Multi-region regulated workforce access | Global enterprises in EU, US, APAC under GDPR/data residency | Centralized policy enforcement with regional data residency via regional IdP deployments | 50K+ employees across continents | Per-region accounts create silos and audit gaps; central IdP without region awareness violates GDPR |
| B2B SaaS enterprise SSO | Notion, Linear, Asana — sold to enterprise customers | "Bring your own IdP" via SAML/OIDC federation — enterprise customers use their own IdP | 10K-100K enterprise customers per platform | Local accounts get rejected by enterprise security review; can't sell into Fortune 1000 |
| Partner / vendor federation | Defense contractors, financial consortia, healthcare HIE | External orgs access your apps with their own IdP — no shadow accounts | Hundreds of partner orgs per federation | Shadow accounts have lifecycle problems; rarely deprovisioned; least-privilege violated |
| M&A identity consolidation | Post-acquisition integration of acquired company identities into parent IdP | One IdP to rule them all; deprecate legacy IdPs over 18-24 month migration | Acquired companies of 1K-50K employees being integrated | Running parallel IdPs indefinitely is operational nightmare; identity inconsistency creates security gaps |
Auth0 — Use Cases
Best for fast CIAM delivery, polished hosted login, social login, and B2B Organizations while accepting per-MAU cost growth and Actions lock-in.
| Use Case | Company / Scenario | Driving Property | Scale Dimension | Why Not Alternative |
|---|---|---|---|---|
| Consumer SaaS startup MVP | YC startup launching with social + email login | Days-to-ship; free tier 7,500 MAU; out-of-the-box Universal Login | 0-10K MAU at startup scale | Keycloak ops overhead is real cost; Cognito admin UX is rough; Auth0 wins at small scale |
| B2B SaaS with multi-tenant CIAM | Mid-market B2B — Linear, Pitch, Vercel during growth phase | Organizations feature for tenant isolation; enterprise SSO via SAML/OIDC for customers | 10K-1M MAU; hundreds of B2B tenants | Keycloak realms work but require ops investment; Cognito B2B story is weaker |
| Passwordless / passkey-first CIAM | Modern fintech, crypto, consumer apps launching post-2024 | Native passkey support, WebAuthn primitives, Conditional UI baked in | 1M-100M MAU at scale-up fintech | Keycloak passkey support is recent (Keycloak 22+) and less polished; Cognito passkey lags |
| API authorization for SaaS APIs | Stripe-like API products needing OAuth 2.0 for third-party developers | Polished developer portal, API authz, fine-grained scopes, M2M grants | Thousands of third-party developers, millions of API calls | Keycloak handles M2M but developer UX is less polished; Cognito M2M flow exists but minimal |
| Regulated consumer apps (healthcare, finance) | Telehealth, digital banking apps | HIPAA / PCI / SOC 2 / FedRAMP Moderate compliance built-in; BAA available | 500K-50M MAU at regulated consumer platforms | Keycloak compliance is self-attested; Cognito has FedRAMP via AWS but less CIAM-specific posture |
| Migration from homegrown auth | Pre-IPO companies replacing legacy auth before scaling | Drop-in OIDC compliance, migration tools, dual-stack support during transition | 10K-100K users mid-migration | Keycloak migration requires more architectural work; Cognito has limited migration tooling |
Keycloak — Use Cases
Choose when open source control, data sovereignty, and per-user cost avoidance justify operating a critical Java/Postgres identity service yourself.
| Use Case | Company / Scenario | Driving Property | Scale Dimension | Why Not Alternative |
|---|---|---|---|---|
| Cost-driven CIAM at scale | 50K+ MAU B2C companies; high-traffic gov / education platforms | $0 per-user; infrastructure-only cost; saves $162K-$942K/year vs Auth0/Okta at 100K users | 50K-10M MAU per deployment | Auth0/Okta per-MAU pricing crosses $100K/year crossover with Keycloak ops cost |
| Sovereign / air-gapped deployments | Government, defense, financial regulators, EU sovereignty-mandated apps | Self-hosted, on-prem, full data residency, no SaaS vendor in the loop | Tens of thousands to millions of identities per sovereign deployment | Auth0 / Okta / Cognito are SaaS; sovereignty regulations explicitly require self-hosted |
| OpenShift / Red Hat ecosystem integration | Enterprises standardized on Red Hat OpenShift / Ansible / RHEL | Red Hat Single Sign-On (commercial Keycloak) is part of OpenShift; ecosystem alignment | 10K-100K users at Red Hat-aligned enterprises | Auth0 / Okta integrate but aren't Red Hat-native; Cognito is AWS-native, not Red Hat |
| EU GDPR-strict workforce + CIAM | EU-based enterprises with strong data sovereignty preferences | Data never leaves EU; full control over user data handling and breach response | 5K-500K identities | Auth0 / Okta have EU regions but you trust the SaaS vendor; Cognito has EU regions but is AWS-bound |
| Identity broker hub for multi-IdP federation | Universities (Shibboleth replacement), B2B SaaS with many partner IdPs | Keycloak's identity brokering is strong; federates dozens of external IdPs through one interface | 500+ external IdPs federated through one Keycloak | Auth0 / Okta support federation but at higher cost-per-IdP and less flexibility |
| Internal-only IdP for engineering platforms | Mid-large tech companies — internal platforms (Backstage, Argo, Grafana) | Self-hosted, OIDC-compliant, fits internal ops culture (K8s-native via Keycloak Operator) | 1K-50K internal users | External SaaS IdPs for internal-only is overkill cost; Keycloak fits internal tooling culture |
Okta — Use Cases
Best for workforce identity, app catalog breadth, lifecycle management, governance, adaptive access, and enterprise integration depth.
| Use Case | Company / Scenario | Driving Property | Scale Dimension | Why Not Alternative |
|---|---|---|---|---|
| Workforce IAM for enterprises (1K-500K employees) | Fortune 500 workforce identity standard; "we use Okta" is shorthand at scale | 7,000+ app integrations (OIN), lifecycle management, deep AD/LDAP federation | Hundreds of thousands of employees per enterprise | Auth0 is CIAM-focused, not workforce; Keycloak workforce IAM requires extensive customization; Cognito is consumer-grade |
| Identity Governance & Administration (IGA) | Regulated enterprises needing SoD, access reviews, certification campaigns | Okta Identity Governance provides full IGA stack | 10K-100K employees with complex governance needs | Auth0 / Keycloak lack IGA; need separate IGA vendor (SailPoint, Saviynt) without Okta |
| Zero Trust workforce access | Cloudflare Zero Trust + Okta, Tailscale + Okta integrations | Adaptive policy with device trust, network signals, continuous evaluation | Workforce of 10K-500K across global enterprises | Auth0 adaptive is competitive for CIAM but Okta is workforce-strong; Keycloak adaptive requires custom SPIs |
| M&A identity consolidation | Post-acquisition rapid identity unification | Universal Directory aggregates AD/LDAP/HRIS sources into one identity layer | Acquired companies of 5K-50K employees being onboarded | Auth0 isn't designed for workforce M&A; Keycloak federation works but Okta's tooling is purpose-built |
| Hybrid (workforce + CIAM via Auth0) | Companies that need both Okta Workforce + Auth0 CIAM under one vendor relationship | Single vendor, integrated billing, partner enablement; Auth0 part of Okta since 2021 | 10K workforce + 1M+ CIAM identities | Multi-vendor IAM stack has coordination overhead; Okta+Auth0 is a unified platform play |
| FedRAMP High / regulated US gov workloads | Federal agencies, defense contractors | Okta has FedRAMP High (only enterprise IdP at this level for years) | Hundreds of thousands of federal employees + contractors | Auth0 FedRAMP Moderate; Cognito via GovCloud; Keycloak FedRAMP requires you to do the work |
AWS Cognito — Use Cases
Use for AWS-native user pools, IAM credential bridging, serverless/mobile backends, and low commercial CIAM cost when admin UX trade-offs are acceptable.
| Use Case | Company / Scenario | Driving Property | Scale Dimension | Why Not Alternative |
|---|---|---|---|---|
| AWS-native mobile / SPA backend | Apps with API Gateway + Lambda + DynamoDB stack | Native IAM role assumption via Identity Pools; signed AWS API calls from client | 1K-10M MAU at AWS-centric apps | Auth0 / Okta require glue code for IAM role assumption; Keycloak even more so |
| Cost-sensitive consumer apps in AWS | Startups and mid-market with cost discipline, all-AWS infrastructure | 50K MAU free tier; $0.0055/MAU above — cheapest commercial CIAM at scale | 50K-10M MAU; cost-conscious teams | Auth0 free tier ends at 7.5K MAU; Okta is enterprise-priced; Keycloak requires SRE time |
| Internal apps deployed via AWS | Enterprise internal tools on EKS / ECS / Lambda | Tight integration with AWS API Gateway authorizers, IAM, Cognito SDK | 500-50K internal users | External IdPs for internal-only AWS apps is cost overkill; Keycloak adds ops; Cognito fits the infra |
| IoT and serverless flows | AWS IoT Core authentication, mobile + serverless backends | Cognito Identity Pools issue STS credentials for IoT MQTT, Lambda invocation, S3 direct uploads | Millions of IoT devices; serverless apps | Other IdPs require custom token-to-IAM bridging; Cognito is the IAM-native pattern |
| Compliance via AWS (HIPAA, FedRAMP, PCI) | Apps that need compliance posture inherited from AWS | AWS GovCloud, HIPAA-eligible, FedRAMP via AWS umbrella | Regulated apps at varying scales | Auth0 / Okta have own compliance but separate audit; AWS compliance is unified for AWS-native apps |
3. Limitations
| Limitation | Centralized IdP | Auth0 | Keycloak | Okta | AWS Cognito |
|---|---|---|---|---|---|
| Vendor lock-in / migration cost | High Architectural concern | High Actions, Rules, Hooks, Organizations don't port | Medium Open source but custom SPIs and theme work don't port | High Workflows, Universal Directory schema, custom integrations | Medium Lambda triggers tied to AWS; user pools schema-locked |
| Cost at scale (above 100K MAU) | N/A — depends on platform | High $0.07/MAU + add-ons; $30K-300K+/mo at 100K-500K MAU | Medium Infra cost only; ~$2K-20K/mo all-in for typical deployments | Critical Per-user-per-feature; routinely $1M+/year at 50K+ users | Medium Base tier cheap; ASF tier raises costs |
| B2B multi-tenant capabilities | N/A — architectural pattern | Medium Organizations feature; paid tier required | Medium Realms work but shared infra; strong isolation needs per-tenant deploy | Medium Workforce-focused; B2B requires careful UD schema | High No native Organizations concept; multi-tenancy requires custom layering |
| Admin UX / operator productivity | N/A | Medium Universal Login admin polished; Actions debugging is harder | Medium Admin Console functional; theme/extension dev requires Java/Freemarker | Medium Admin Console robust; pricing surface adds operator complexity | High Console is barebones; AWS CLI / CDK is the real interface |
| Operational complexity | High Multi-region IdP HA is non-trivial | Medium SaaS; ops handled by vendor | Critical Self-hosted; HA, scaling, patching, monitoring all on you | Medium SaaS; ops handled by vendor | Medium Managed by AWS; configuration complexity in IaC |
| Compliance certifications | N/A | Medium SOC 2, ISO 27001, HIPAA, FedRAMP Moderate | High You inherit the burden of certifying self-hosted | Medium SOC 2, ISO 27001, HITRUST, FedRAMP High | Medium Inherits AWS compliance; HIPAA, FedRAMP via AWS |
| Customization depth | N/A | Medium Actions/Rules are JavaScript; deep but locked-in | Medium Java SPIs allow anything but at engineering cost | Medium Workflows + custom Hooks; powerful but priced | Medium Lambda triggers in TS/Python/etc.; latency cost |
| FIDO2 / Passkey readiness | N/A — depends on platform | Medium Native passkey + Conditional UI support | Medium Passkey support since Keycloak 22; improving | Medium FastPass (proprietary) + standard passkeys | Medium WebAuthn support; less polished than Auth0 |
| Migration in (importing users) | N/A | Medium Migration tools; password hash import; bulk import APIs | Medium User storage SPI for legacy DBs; migration tools available | Medium Robust import tooling; LDAP / AD direct connect | High Limited migration tooling; custom Lambda for password migration |
4. Fault Tolerance
| Dimension | Centralized IdP | Auth0 | Keycloak | Okta | AWS Cognito |
|---|---|---|---|---|---|
| Replication model | Multi-region active-active is the target | Multi-region active-active; PrivateCloud option for dedicated tenancy | Multi-region requires explicit setup; Infinispan for session cache replication | Multi-region active-active; geo-redundant by default | Multi-AZ within region by default; multi-region requires customer architecture |
| Failure detection | Client-side timeout/5xx detection; health checks on AS endpoints | Auth0 status page; SLA-monitored uptime | You operate it — Prometheus, K8s health probes, custom dashboards | Okta status page; SLA-monitored uptime | CloudWatch metrics; AWS SLA |
| Failover mechanism | Health-checked DNS routing across regional IdPs | Transparent to clients — Auth0 handles internally | Manual or operator-driven — region failover requires engineering | Transparent to clients — Okta handles internally | Region-bound by default; multi-region requires user pool federation |
| RTO (typical) | Minutes for IdP recovery; hours for IdP migration in true disaster | Seconds to minutes — Auth0 SLA: 99.99% Enterprise | Depends on your operations; minutes if well-engineered, hours otherwise | Seconds to minutes — Okta SLA: 99.99% Enterprise | Minutes to hours for region failure; depends on your multi-region setup |
| RPO (typical) | 0 for issued tokens; user data loss depends on backup | 0 — Auth0 replicates user store across regions | 0 if DB is replicated; could be seconds if async replication | 0 — Okta replicates user store across regions | 0 within region; depends on customer multi-region replication strategy |
| Split-brain behavior | Token issuance can continue independently in partitioned regions; key rotation must coordinate | Handled internally by Auth0 control plane | You design the split-brain semantics; typical: read-only fallback during partition | Handled internally by Okta control plane | Single-region by default; multi-region needs careful design to avoid split-brain |
| Blast radius of single-node failure | One node = transparent failover; depends on N-redundancy | Transparent — Auth0 handles internally | Single node failure handled by Keycloak cluster; load redistributes | Transparent — Okta handles internally | Transparent — AWS handles AZ failures internally |
| Cross-region failover story | Multi-region active-active is gold standard for serious deployments | Built-in; PrivateCloud Multi-Region adds dedicated SLA | You engineer it; sync DB replication is non-trivial | Built-in; geo-redundancy default for Enterprise | Customer-engineered via user pool federation across regions |
| Data loss scenarios | Loss of IdP user store = effectively complete identity loss; backups not optional | Auth0 documented backup posture; user Log Streams recommended for own backups | Loss of Postgres = identity loss; standard DR practices apply | Okta backup posture; admin export capabilities for data portability | Cognito user pool export limited; Lambda-based export for backup is the pattern |
6. HA & Replication
| Dimension | Centralized IdP | Auth0 | Keycloak | Okta | AWS Cognito |
|---|---|---|---|---|---|
| Replication topology | Architectural — active-active multi-region is the target | Active-active multi-region; PrivateCloud Multi-Region option | Single-region default; multi-region via DB replication + Infinispan | Active-active multi-region; transparent to customer | Multi-AZ within region by default; multi-region is customer architecture |
| Sync vs async | Architectural choice | Sync within region, async cross-region | Sync within cluster (Postgres + Infinispan); async cross-region typically | Sync within region, async cross-region | Sync within region; cross-region requires customer-driven sync |
| Replication factor | Architectural — typically 3+ for production HA | 3+ regional zones; not customer-configurable on standard tier | Configurable; typically 3-node minimum for production HA | 3+ regional zones; transparent to customer | Multi-AZ default; replication factor managed by AWS |
| Consistency level options | N/A — pick the platform | Eventually consistent across regions; strong within region | Strong consistency within Postgres; cluster cache eventually consistent | Same as Auth0 — strong within region, eventual cross-region | Strong within region; cross-region requires customer sync logic |
| Replication lag (typical) | N/A | Sub-second within region; 1-5s cross-region | Sub-second within cluster; depends on cross-region DB replication setup | Sub-second within region; 1-5s cross-region | Sub-second within region; customer-managed cross-region |
| Conflict resolution | N/A | Last-writer-wins for user attribute conflicts | DB-level; depends on replication strategy | Last-writer-wins; conflict logging available | Last-writer-wins; customer-managed cross-region |
| Cross-region replication | Architectural — the bar for serious IdP deployments | Active-active across regions on Enterprise / PrivateCloud Multi-Region | Customer-architected; common with bi-directional Postgres replication | Active-active across regions on Enterprise tier | Customer-architected; user pool federation pattern |
| Replication during partition | N/A | Partitioned region serves cached state; new writes blocked | Depends on Postgres replication strategy | Partitioned region serves cached state; new writes blocked | Region partition: existing tokens valid; new logins blocked in partitioned region |
7. Better Usage Patterns
Centralized IdP — Better Usage
Use the centralized IdP pattern when identity policy, lifecycle, MFA, federation, and audit need one durable control plane across many applications.
| Pattern | What Most Teams Do Wrong | The Better Way | Why It Matters |
|---|---|---|---|
| Multi-region active-active by default | Single-region IdP with cold DR or "we'll fix it later" | Active-active multi-region from day one; health-checked routing | IdP outage = entire org cannot work. Cold DR has hours of RTO. Active-active is the only acceptable answer. |
| Phishing-resistant MFA at the IdP | Password + SMS as the workforce IdP authn method | Passkeys / FIDO2 hardware keys as primary authn; passwords as legacy fallback | The IdP amplifies single credential compromise to N apps. Phishing-resistant MFA is the only defense that survives that blast radius. |
| SCIM-driven lifecycle automation | Manual provisioning per app; manual deprovisioning at offboarding | SCIM 2.0 from IdP to every supported app; full lifecycle automation | Manual offboarding has lag (days to weeks). SCIM-driven offboarding is instant. The gap is where insider risk lives. |
| Acr/amr claims for per-app assurance | One global authn context for all apps | Define acr values for assurance tiers; enforce per-app; step up across tiers | Email needs lower assurance than admin. Without acr, you over-prompt or under-protect. Cedar/OPA can enforce uniformly. |
| Short session TTL + active revocation | 8-hour or 30-day sessions; no revocation mechanism | 15-30 min token TTL + CAE/SSF for active session revocation + back-channel logout | Long sessions = long compromise windows. With passkeys, re-auth is one tap. Active revocation closes the deprovisioning gap. |
| IdP as protocol implementation, not platform | Encode business logic in IdP rules / actions / workflows | IdP handles authn + minimal claim enrichment; business logic in your services | IdP-locked business logic is the lock-in mechanism. Limit IdP customization to authn-specific concerns. |
Auth0 — Better Usage
Best for fast CIAM delivery, polished hosted login, social login, and B2B Organizations while accepting per-MAU cost growth and Actions lock-in.
| Pattern | What Most Teams Do Wrong | The Better Way | Why It Matters |
|---|---|---|---|
| Universal Login + custom domain from day one | Default auth0.com domain in production; embedded login in some apps | Universal Login with custom domain (auth.yourbrand.com); centralized authn surface | Embedded login defeats phishing resistance. Universal Login with custom domain is the production pattern. |
| Log Streams to your own SIEM | Rely on Auth0's built-in log retention (30 days base) | Set up Log Streams to S3 / Datadog / Splunk from day one; long-term retention | 30-day retention is insufficient for audit. Log Streams cost is small relative to audit value. |
| Organizations for B2B from start | Build B2B multi-tenancy as "tenant_id custom claim" hack | Use Organizations feature; one Organization per B2B customer | Roll-your-own multi-tenancy on top of single Auth0 tenant is technical debt. Organizations is the supported pattern. |
| Actions for authn-specific logic only | Put business logic in Actions ("on login, check user's subscription tier and..." ) | Actions handle claim enrichment + conditional MFA; business logic in your services | Actions are the lock-in mechanism. Migration to another IdP means rewriting all Actions. Keep them minimal. |
| Lock down management API access | Long-lived M2M tokens with broad scopes for admin operations | Short-lived M2M tokens with minimum-required scopes; rotate keys quarterly | Management API access = full IdP control. Compromise is catastrophic. Treat like cloud root credentials. |
| Tenant per environment | One Auth0 tenant for prod, staging, dev — separated by tenant URL | Separate Auth0 tenants per environment; deploy via tenant deploy tooling | Shared tenant means misconfigured dev rule can affect prod. Tenant-per-env is the supported pattern. |
Keycloak — Better Usage
Choose when open source control, data sovereignty, and per-user cost avoidance justify operating a critical Java/Postgres identity service yourself.
| Pattern | What Most Teams Do Wrong | The Better Way | Why It Matters |
|---|---|---|---|
| Sized for HA from day one | Single-node Keycloak in K8s with no HA | 3+ node cluster with Infinispan, Postgres HA, load balancer with sticky sessions | Single-node Keycloak is a SPOF for every authenticated app. Treat as a critical service from day one. |
| Session storage on Infinispan / Redis | Default DB-backed sessions, then surprised by Postgres bottleneck | Move sessions to Infinispan distributed cache; offload session reads from Postgres | At 10K+ active sessions, DB session storage hits connection pool limits. Cache-backed sessions scale far better. |
| Realm isolation per tenant for B2B | One realm with tenant attribute on users | One realm per tenant (B2B); shared cluster but logical isolation | Single-realm B2B mixes tenant data and complicates RBAC. Realm-per-tenant provides clean isolation. |
| Quarkus-based Keycloak (modern distribution) | Legacy WildFly-based Keycloak 17 or earlier in production | Keycloak 22+ (Quarkus); 5x faster startup, 60% lower memory | Legacy WildFly Keycloak is no longer supported. Migration to Quarkus is necessary for new builds. |
| Backups + DR drills | Postgres backed up but never restored in DR test | Regular DR exercises restoring realms from backup; documented recovery runbook | Backups untested are aspirational. Postgres restore + realm verification needs practice before the real incident. |
| Theming via approved patterns | Edit Keycloak built-in themes (lost on upgrade) | Create a custom theme extending base; version-controlled in your IaC | Built-in themes are overwritten on upgrade. Custom themes are the supported path; they survive upgrades. |
Okta — Better Usage
Best for workforce identity, app catalog breadth, lifecycle management, governance, adaptive access, and enterprise integration depth.
| Pattern | What Most Teams Do Wrong | The Better Way | Why It Matters |
|---|---|---|---|
| Post-Lapsus$ hardening | Default policies; admin access via username/password | Admin console behind IP allowlist; hardware key required for super admins; FastPass for users | The 2022 Lapsus$ incident exposed support-tier compromise. Okta's hardening capabilities are good if configured. |
| Universal Directory schema design | Ad-hoc attribute additions over time, schema rot | Designed schema with namespaced custom attributes; documented and reviewed | Universal Directory is the entity model for your identity domain. Schema mistakes haunt you for years. |
| Adaptive MFA with intelligent thresholds | Adaptive MFA enabled with default policies; high false-positive rate | Tune risk thresholds based on user populations; corp travel calendar integration; geo signals | Default adaptive thresholds are conservative. Tune to your risk profile to reduce friction. |
| SCIM provisioning to every supported app | Provision via Okta but deprovision manually | End-to-end SCIM lifecycle; automatic deprovisioning on user disable | Manual offboarding has measurable lag. Full SCIM lifecycle closes the gap that's been the source of multiple breaches. |
| Workflows for IGA-like flows | Custom code outside Okta for access reviews, JIT access requests | Okta Workflows for low-code access governance; integrate with ticketing | Okta Workflows is genuinely powerful but underused. Saves significant custom code for access governance flows. |
| Cost transparency reviews quarterly | "We use Okta" without per-feature cost tracking; renewal sticker shock | Quarterly cost review by feature; flag features approaching tier boundaries before renewal | Okta pricing surface is opaque and stacks fast. Without review, you walk into renewals blind. |
AWS Cognito — Better Usage
Use for AWS-native user pools, IAM credential bridging, serverless/mobile backends, and low commercial CIAM cost when admin UX trade-offs are acceptable.
| Pattern | What Most Teams Do Wrong | The Better Way | Why It Matters |
|---|---|---|---|
| Use Identity Pools only when needed | Enable Identity Pools always, even for apps not assuming IAM roles | User Pools for managed users; Identity Pools only when client needs IAM credentials | Identity Pools add complexity. Many apps need only User Pools. Don't enable both unless you use both. |
| Lambda triggers kept lightweight | Heavy business logic in pre-token-generation Lambda | Triggers fast (under 100ms p99); idempotent; defer heavy work to async paths | Auth flow latency adds up: 5 triggers × 200ms = 1s added login latency. Users notice. |
| Multi-region via federation | Single-region User Pool with no cross-region story | Federate User Pools across regions; or use multi-region with custom Lambda sync | Single-region pool = regional outage = full auth outage. Federation is the supported pattern. |
| Custom admin UI for operators | Customer support uses AWS Console for user lookups (slow, clunky) | Build a custom admin UI calling Cognito Admin APIs; tailored for support team needs | Cognito Console is barebones. A small admin UI investment significantly reduces support time-per-ticket. |
| ASF cost forecasting | Enable Advanced Security Features without modeling cost | Run cost model with realistic MAU + ASF assumptions before enabling broadly | ASF cost jump is meaningful at scale. Forecast before turning on, not after the AWS bill arrives. |
| User pool export for portability | Assume Cognito users can't be exported; lock-in panic at scale | Lambda-based export with hashed passwords (for compatible migration); design for portability from start | Cognito has limited native export tooling. Build your own user-data export at low scale. |
8. Advanced / Next-Gen Alternatives
Centralized IdP — Successors / Adjacent
Use the centralized IdP pattern when identity policy, lifecycle, MFA, federation, and audit need one durable control plane across many applications.
| Successor / Alternative | What It Improves | Maturity | Migration Cost | When To Consider |
|---|---|---|---|---|
| Decentralized Identity (DID + Verifiable Credentials) | User holds credentials in a wallet; presents to RPs without IdP roundtrip; no central authority required | Early Adopter EU eIDAS 2.0 mandate (Q4 2026 deadline), W3C DID spec, OIDC4VC bridge | Very High — entire stack rewrite; wallet ecosystem dependency | EU consumer identity (eIDAS mandate); high-value identity proofing flows. |
| OpenID Federation 1.0 | Hierarchical trust chains replacing bilateral IdP federation | Emerging Early production (Sweden BankID, Italy SPID) in 2025-2026 | Medium — existing IdPs add federation operator role | Multi-org federations (gov, education, healthcare consortia) over 2026-2030. |
| Continuous Access Evaluation (CAE) + SSF | Real-time policy enforcement across federated apps; replaces stale-token problem | Production Microsoft Entra CAE; OpenID Shared Signals at Google, Okta | Medium — apps must support CAE/SSF receiver endpoints | All 2026 IdP deployments where deprovisioning lag matters (regulated, high-value). |
| Workload identity (SPIFFE/SPIRE) | Standardized workload identity for service mesh; complements user IdP | Production CNCF Graduated; Bloomberg, Pinterest, Square at scale | Medium — SPIRE deployment; integrates with Istio/Linkerd | Service-mesh architectures where user IdP + workload IdP are both required. |
| FedCM (browser-mediated federation) | Replaces third-party-cookie federation; browser is intermediary | Emerging Chrome 117+; Google mandates for One Tap; Firefox in progress; Safari no plan | Medium — IdP + RP additions; libraries support it | Consumer-facing apps using third-party-cookie-based federation must migrate. |
Auth0 — Alternatives
Best for fast CIAM delivery, polished hosted login, social login, and B2B Organizations while accepting per-MAU cost growth and Actions lock-in.
| Alternative | What It Improves | Maturity | Migration Cost | When To Consider |
|---|---|---|---|---|
| Keycloak (open source) | Eliminates per-MAU pricing; full control; data sovereignty | Production at Scale Used at major banks, governments, enterprises | Medium-High — Actions/Rules don't port; theme work; operational ramp | 50K+ MAU where cost crossover triggers; sovereignty requirements. |
| Ory (Kratos + Hydra + Keto) | API-composable headless identity; modern Go-based; OpenAI, Cisco, Klarna at scale | Production Mature in 2026 after years of dev | High — different model (headless), build your own UI | Teams with UI/UX engineering capacity; API-first architectures. |
| SuperTokens (self-hosted + managed) | Lighter than Keycloak; modern stack; flexible deployment | Production Growing adoption; smaller ecosystem than Keycloak | Medium — modern API; less mature ecosystem | Mid-market SaaS wanting self-hosted without Keycloak's Java footprint. |
| WorkOS (B2B SSO/SCIM as a service) | B2B-only focus; pre-built SAML/SCIM connectors; simpler than full IAM | Production Used by Vercel, OpenAI, Webflow, Plaid | Medium — narrower scope; pair with another IdP for non-B2B flows | B2B SaaS that needs enterprise SSO but doesn't need full CIAM. |
| Clerk (modern CIAM, dev-first) | Drop-in React/Next.js components; passkey-first; opinionated | Production Growing in startup ecosystem | Medium — opinionated; React-first; limited SAML on Pro tier | Modern web app startups with React/Next.js stack. |
Keycloak — Alternatives
Choose when open source control, data sovereignty, and per-user cost avoidance justify operating a critical Java/Postgres identity service yourself.
| Alternative | What It Improves | Maturity | Migration Cost | When To Consider |
|---|---|---|---|---|
| Authentik (modern open-source IdP) | Lighter than Keycloak; modern Python stack; Docker-native | Production Growing adoption; smaller community than Keycloak | Medium — different config model; migrate users and flows | Smaller self-hosted deployments where Keycloak's Java footprint is heavy. |
| Ory Stack (Kratos, Hydra, Keto, Oathkeeper) | Composable headless identity; cloud-native architecture | Production Mature in 2026; major enterprise adoption | High — full migration; rebuild UI | Engineering-heavy teams wanting API-first identity stack. |
| Red Hat build of Keycloak (commercial) | Commercial support; LTS releases; certified for Red Hat OpenShift | Production Long-standing enterprise commercial offering | Low — same Keycloak with support contract | Production deployments wanting commercial support without leaving Keycloak. |
| Managed Keycloak (Phasetwo, KeycloakPro) | Keycloak-as-a-service; you don't run infrastructure | Production Growing market 2025-2026 | Low — same Keycloak; managed by vendor | Teams wanting Keycloak's feature set without operational burden. |
Okta — Alternatives
Best for workforce identity, app catalog breadth, lifecycle management, governance, adaptive access, and enterprise integration depth.
| Alternative | What It Improves | Maturity | Migration Cost | When To Consider |
|---|---|---|---|---|
| Microsoft Entra ID (formerly Azure AD) | Tighter Microsoft 365 integration; Conditional Access; lower TCO for MS-heavy shops | Production at Scale Industry-standard alternative to Okta for workforce | High — workforce migration is a major project | Microsoft 365 / Office 365 / Azure-heavy organizations. |
| Ping Identity | Federated identity heritage; strong SAML/B2B; competitive enterprise pricing | Production at Scale Long-standing Okta competitor | High — migration project | Enterprises with heavy SAML / federation needs and price-sensitivity. |
| JumpCloud | Workforce IAM + device management + MDM in one; SMB-friendly pricing | Production Strong in SMB / mid-market | Medium — migration project | SMB / mid-market workforce IAM where bundling device mgmt matters. |
| SailPoint Identity Security Cloud | Deeper IGA than Okta; focused on governance, not authn | Production at Scale IGA market leader | High — different category, may complement rather than replace | Regulated enterprises needing strong IGA alongside authn IdP. |
AWS Cognito — Alternatives
Use for AWS-native user pools, IAM credential bridging, serverless/mobile backends, and low commercial CIAM cost when admin UX trade-offs are acceptable.
| Alternative | What It Improves | Maturity | Migration Cost | When To Consider |
|---|---|---|---|---|
| Auth0 (with AWS integrations) | Better admin UX; richer features; better B2B story | Production at Scale | High — auth flow rewrite | When the cost saving from Cognito doesn't justify the admin UX pain. |
| FusionAuth (self-hosted CIAM) | Self-hosted; can replace Cognito for AWS-native apps wanting more control | Production Growing adoption | Medium-High — migration project | Cost-conscious teams wanting Cognito-class features with self-hosted control. |
| Frontegg (B2B CIAM) | B2B SaaS-specific features (entitlements, audit, customer admin); better than Cognito for B2B | Production Growing in B2B SaaS | Medium — different model; B2B-focused | B2B SaaS apps that started on Cognito and need richer B2B identity features. |
| AWS IAM Identity Center (workforce) | Workforce IAM for AWS Console / CLI access; replaces Cognito for workforce-AWS | Production AWS-native workforce IAM | Medium — purpose-built for AWS workforce access | Workforce-AWS access; different category from CIAM Cognito User Pools. |