SSO and Identity Providers in 2026 - A Deep Dive into Keycloak 26, Authentik, Authelia, Auth0, Okta, AWS Cognito, and Microsoft Entra ID

Prologue - In 2026, SSO Is No Longer Optional

In the 2010s SSO was "a luxury big companies own." In the early 2020s it sat in a grey zone of "necessary but expensive." In 2026 SSO is the default infrastructure of every organization.

The reasons are simple.

• An average person uses more than 80 SaaS products, and tracking joiners and leavers by hand is impossible.
• NIS2 (EU), DORA (EU finance), PCI DSS 4.0.1, HIPAA Security Rule 2024, and SOC 2 Type II all explicitly require centralized IAM, MFA, and session visibility.
• Passkeys (WebAuthn / FIDO2) are now synchronizable across Apple, Google, and Microsoft accounts, making passwordless login a reality for ordinary users.
• Incidents like Auth0 lock-in, Cognito feature deprecation, and the ForgeRock to Ping consolidation shook trust in managed IdPs and renewed interest in open-source alternatives like Keycloak, Authentik, and Ory.

This article maps the full terrain in one place. We start with the standards, walk through open-source IdPs, then managed SaaS, then library-camp options, then the rising separation of authorization, and finally the realities in Korea and Japan.

One-line summary: "Who authenticates, who authorizes, where the evidence of those decisions lives, and how people are cleaned up when they leave." If you cannot answer these four questions, no IdP you install will save you.

Chapter 1 - The Real Problem SSO Solves: People, Accounts, Sessions, Audit

If you understand SSO as "log in once," you miss the point. The real problem has four layers.

On top of these come provisioning / deprovisioning (SCIM), authorization decisions, MFA enforcement, and adaptive risk detection.

A good SSO is not "login unification" - it is "treating the human lifecycle as infrastructure."

Chapter 2 - Core Standards: OAuth 2.1, OIDC, SAML, SCIM, WebAuthn

Five standards to know in 2026.

OAuth 2.1 is the IETF consolidation of OAuth 2.0 best practices into one mandatory profile. Four things became MUST.

1. PKCE (Proof Key for Code Exchange) is mandatory for every client.
2. Implicit flow is removed. SPAs use Authorization Code + PKCE.
3. Resource Owner Password Credentials grant is removed.
4. Redirect URI exact match - no wildcards.

OIDC adds an ID Token (a signed JWT) on top of OAuth, letting a server say "the bearer of this token is really user X." Standard claims include iss, sub, aud, exp, iat, and nonce.

SAML 2.0 is a relic of the XML / SOAP era, yet it remains over 90 percent of enterprise SSO. Too many SaaS apps still speak only SAML.

SCIM 2.0 lets an IdP automatically populate user directories in downstream SaaS. "An employee leaves in Okta and Slack disables them automatically" is daily life with SCIM.

WebAuthn / FIDO2 is public-key authentication that removes the password itself. Between 2024 and 2026, iCloud Keychain, Google Password Manager, 1Password, and Bitwarden all added Passkey synchronization, effectively making passwordless the consumer default.

Chapter 3 - OAuth 2.1: PKCE, PAR, JAR, DPoP

Four security extensions have become standard on top of OAuth 2.1.

PKCE (RFC 7636) prevents authorization code interception. The client generates a random code_verifier, sends its SHA-256 hash (code_challenge) in the authorization request, and proves possession by resubmitting code_verifier at token exchange.

PAR (Pushed Authorization Requests, RFC 9126) pushes authorization parameters to the IdP over a back channel instead of exposing them in the browser URL. The browser only carries the returned request_uri.

JAR (JWT-Secured Authorization Request, RFC 9101) sends the authorization request itself as a signed JWT, preventing parameter tampering.

DPoP (Demonstrating Proof-of-Possession, RFC 9449) addresses the weakness of bearer tokens (anyone in possession can use them). The client attaches a DPoP header signed by its own key on every request, proving "this token is bound to my key."

The 2026 IETF OAuth 2.0 Security BCP draft effectively recommends or requires all four.

# Pseudo flow - Authorization Code plus PKCE plus PAR plus DPoP
# 1) Client pushes authorization params via PAR
POST /as/par
   client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256
# 2) IdP returns request_uri
# 3) Browser only carries request_uri to the IdP
GET /as/authorize?client_id=...&request_uri=urn:ietf:params:oauth:request_uri:abc
# 4) After login, IdP redirects to redirect_uri with code
# 5) Client exchanges code plus code_verifier at the token endpoint
# 6) Every subsequent resource request carries a DPoP header

Chapter 4 - OIDC: ID Token, Userinfo, Discovery, Logout

OIDC differs from OAuth in three ways.

1. ID Token - a JWT containing user information is issued alongside the access token.
2. /userinfo endpoint - a way to fetch the user profile with the access token.
3. Discovery document - /.well-known/openid-configuration exposes every endpoint and key location.

A standard ID Token payload looks like this.

{
  "iss": "https://idp.example.com/realms/main",
  "sub": "8af2a1b8-f1a0-4d5c-a3a0-d10a3b9c9e22",
  "aud": "my-app",
  "exp": 1747459200,
  "iat": 1747455600,
  "nonce": "c6f3b1e2c0f7",
  "auth_time": 1747455600,
  "acr": "urn:mace:incommon:iap:silver",
  "email": "alice@example.com",
  "email_verified": true,
  "preferred_username": "alice"
}

Claims you must validate:

• iss - is this an IdP I trust
• aud - is my client ID the intended audience
• exp and iat - is the time window valid
• nonce - does it match the one I sent in the authorization request
• signature - did I fetch the key from JWKS (jwks_uri) and verify

Single Logout is the part OIDC never quite solved. Back-channel and front-channel logout both have holes. The 2026 operational pattern shifts toward "short access tokens + refresh token rotation + immediate invalidation when the IdP session ends" rather than relying purely on SLO.

Chapter 5 - SAML 2.0: The XML That Refuses to Die

SAML survives in enterprises for two reasons. First, a large portion of installed SaaS speaks only SAML. Second, IT and audit teams know what SAML assertions look like.

The SSO flow is more involved than OIDC.

1. The user hits the SP (Service Provider, for example Salesforce).
2. The SP creates a SAMLRequest and redirects to the IdP (for example Okta).
3. After login the IdP POSTs a signed SAMLResponse (XML) to the SP's ACS URL.
4. The SP validates the assertion and creates a session.

<!-- Simplified SAML Response excerpt -->
<samlp:Response>
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        alice@example.com
      </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="..." NotOnOrAfter="..."/>
    <saml:AttributeStatement>
      <saml:Attribute Name="memberOf">
        <saml:AttributeValue>engineering</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

SAML's weakness is well known. XML Signature Wrapping bypass, assertion replay, and metadata tampering have all been documented. In 2026 the standard pattern is "new integrations use OIDC, legacy SaaS keeps SAML" - a dual-protocol operation.

Chapter 6 - SCIM 2.0: The Provisioning Standard

SCIM (System for Cross-domain Identity Management, RFC 7643 / 7644) is a REST API standard for an IdP to push users and groups into a SaaS directory.

Core endpoints:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice@example.com",
  "name": { "givenName": "Alice", "familyName": "Kim" },
  "emails": [{ "value": "alice@example.com", "primary": true }],
  "active": true,
  "externalId": "8af2a1b8-f1a0-4d5c-a3a0-d10a3b9c9e22"
}

When HR marks an employee as terminated, the IdP PUTs active=false via SCIM to every linked SaaS. A SaaS that fails this step is security debt.

In 2026 a SaaS without SCIM rarely survives the enterprise market. Slack, Notion, Figma, Linear, Datadog, and GitHub Enterprise all support it.

Chapter 7 - WebAuthn / FIDO2 / Passkeys: The End of Passwords

WebAuthn (W3C) and FIDO2 CTAP2 (FIDO Alliance) solve the same problem. The user device stores a private key and signs a challenge during authentication. There is no password at all.

Core flow:

1. Registration - the user generates a key pair on the device and registers only the public key with the server.
2. Authentication - the server sends a challenge, the device signs it with the private key, the server verifies with the public key.

Passkeys are an evolution of WebAuthn authenticators into a synchronizable form. iCloud Keychain, Google Password Manager, 1Password, and Bitwarden now sync passkeys across devices.

// WebAuthn registration - simplified pseudo code
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: serverChallenge,
    rp: { name: "Example App", id: "example.com" },
    user: { id: userIdBuffer, name: "alice", displayName: "Alice" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: {
      authenticatorAttachment: "platform",
      residentKey: "required",
      userVerification: "required"
    }
  }
})
// Send credential.response.attestationObject to the server, verify, store the public key

In 2026 Google, Microsoft, Apple, GitHub, Shopify, PayPal, and Amazon all support Passkey sign-in. In Korea, Kakao, Naver, and Toss are at partial-support stages.

Chapter 8 - Keycloak 26 / 26.1: The De Facto Standard Open-Source IdP

Keycloak is an open-source IdP started by Red Hat in 2014. After 26.0 was released as an LTS line in late 2024, incremental improvements continued through 26.1. As of 2026, it is the de facto standard for self-hosted IdPs.

The 26 line brought several large shifts.

• Quarkus-based rewrite - the WildFly era through 19.x is finished. Quarkus is the single distribution.
• Account Console v3 - a new React + i18n UI for end users to manage their accounts.
• Organizations - a multi-tenancy model that places multiple orgs inside a single realm (GA in 26.0).
• Fine-Grained Admin Permissions v2 - a redesigned model for slicing admin authority by realm and resource.
• mTLS Client Authentication - clients authenticate via mTLS.
• DPoP support - sender-constrained tokens.
• OAuth 2.0 Step-Up Authentication Challenge - request a stronger factor before sensitive actions.

Red Hat build of Keycloak (RHBK) is the commercial distribution that wraps Keycloak with Red Hat's lifecycle and CVE guarantees. The license is still Apache 2.0.

Chapter 9 - Keycloak Core Concepts: Realm, Client, IdP Brokering, User Federation

The confusing part when you first touch Keycloak is the vocabulary.

Identity Brokering lets external Google / GitHub / Microsoft logins flow through Keycloak and be mapped to an internal user. The user authenticates externally, but our app always sees Keycloak.

User Federation is the inverse. An existing LDAP or AD becomes the user source, but Keycloak owns authentication, allowing gradual migration without data movement.

SPI (Service Provider Interface) gives extension points in nearly every area: user storage, authentication flow, event listener, token mapper, email template, and more. Drop a Java jar into the providers/ directory and run the build step to register it.

Chapter 10 - Operating Keycloak: Docker Compose, Helm, PostgreSQL, HA

Honest single-node self-hosting looks like this.

# Simple ops - single node - external Postgres
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: keycloak
      POSTGRES_USER: keycloak
      POSTGRES_PASSWORD: changeme
    volumes:
      - kc_pg:/var/lib/postgresql/data

  keycloak:
    image: quay.io/keycloak/keycloak:26.1
    command: start --optimized
    environment:
      KC_DB: postgres
      KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak
      KC_DB_USERNAME: keycloak
      KC_DB_PASSWORD: changeme
      KC_HOSTNAME: id.example.com
      KC_PROXY_HEADERS: xforwarded
      KC_HTTP_ENABLED: "true"
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: changeme
    ports:
      - "8080:8080"
    depends_on:
      - postgres

volumes:
  kc_pg:

Things to worry about as you approach production.

• HA - Infinispan distributed cache plus Postgres read replicas. The Kubernetes Operator is standard.
• TLS termination - terminate at nginx / HAProxy / Traefik and tell Keycloak to trust proxy headers.
• Backup - all state lives in Postgres. Realm export and import is auxiliary.
• Monitoring - Prometheus metrics at /metrics, event listeners pushing to Kafka or SIEM.
• Themes - apply your design system to login, account, and admin.

The most common operational mistakes: leaving admin passwords as plain env vars forever, exporting realms with secrets included, no Postgres backup policy, and JVM memory left at defaults.

Chapter 11 - Authentik 2025: Beryju's Modern Alternative

Authentik (beryju.io) is a relatively new open-source IdP written in Python / Django. It stabilized through the 2025 line and has solidified second place behind Keycloak.

Distinguishing traits:

• Flow-based authentication - login is a node graph. Adding stages, conditional branches, and external calls are all GUI operations.
• Modern UI - an admin console built with Lit and TypeScript that is openly designed against the clunkiness of Keycloak's admin UI.
• Protocols - OAuth 2.0 / OIDC, SAML 2.0, LDAP (as a server), Proxy, RADIUS are all supported.
• Outpost - auxiliary services like proxy, LDAP, and RADIUS deployed as containers.
• Enterprise - paid plans (GeoIP, Audit, RAC, Wizard) added from 2024.

When starting a self-hosted IdP from scratch in 2026, the default question is "Keycloak vs Authentik." Keycloak wins where heavy LDAP / AD assets exist. Authentik often wins where you start fresh with OIDC only.

Chapter 12 - Authelia 4.39: Self-Hosted 2FA Tied to Your Reverse Proxy

Authelia (authelia.com) is a self-hosted authentication portal written in Go. Its integration model differs from other IdPs.

Core model: enforce authentication via ForwardAuth at nginx / Traefik / Caddy. Authelia is less of an IdP and more of a protective gateway.

# nginx ForwardAuth - Authelia
location /api/verify {
  proxy_pass http://authelia:9091/api/verify;
}

location / {
  auth_request /api/verify;
  auth_request_set $user $upstream_http_remote_user;
  proxy_set_header Remote-User $user;
  proxy_pass http://upstream-app:3000;
}

This model shines in two scenarios.

1. Legacy apps without OIDC support that you still want to put behind unified 2FA.
2. Self-hosted homelab environments where Nextcloud, Jellyfin, Paperless-ngx, and the various ARR tools all need a single front door.

Authelia does ship partial OIDC issuer support, but its main job is being a ForwardAuth gateway. It is a complement to Keycloak and Authentik, not a replacement.

Chapter 13 - Casdoor, Ory Stack, Logto: The New Open-Source Wave

Casdoor (casbin.org) is a modular IAM written in Go. It supports OAuth 2.0 / OIDC, SAML, CAS, LDAP, and RADIUS, and multi-tenancy is natural. Sharing an organization with Casbin (the RBAC / ABAC policy engine) gives it strong authorization.

Ory Stack is a bundle of Go modules.

Ory calls itself headless. It exposes APIs without prepackaged UIs, which fits when you want to integrate into your own Next.js or Flutter UI.

Logto (logto.io) is a newer open-source IdP launched in 2022. Developer experience first - good SDKs, console, dark mode, M2M, RBAC, and Organizations. A managed Cloud option exists too.

SuperTokens and FusionAuth (both commercial and self-hostable) compete in the same slot. License, pricing, and UI quality are the deciders.

Chapter 14 - Auth0: The Managed Classic

Auth0 (founded 2013, acquired by Okta in 2021) is the de facto original of managed IdPs. As of 2026 it remains the default choice for SaaS startups.

Strengths:

• Universal Login - the hosted login page. Auth0 owns security patching.
• Actions / Rules (consolidating under Actions) - hooks where you inject custom JavaScript into the auth flow to add claims, call external APIs, or force MFA.
• Adaptive MFA / Bot Detection - risk-scored MFA enforcement.
• Branding and i18n - nearly every screen is theme- and language-customizable.
• Connections - Database, Social (Google / GitHub / Apple), Enterprise (SAML / AD / LDAP), Passwordless.

The biggest weakness is price and lock-in. Tenant migration exists but deep dependence on Actions, Hooks, Custom DB Actions, and the Lock JS widget makes leaving painful. Between 2024 and 2026 there were several published Auth0 to Keycloak and Auth0 to Clerk migration stories.

Chapter 15 - Okta Workforce and Customer Identity Cloud

Okta is the other pole of managed IdPs. After the August 2022 LAPSUS$ breach and the October 2023 support-system breach, Okta hardened its security operations significantly.

Workforce Identity Cloud (WIC) is the employee-facing IdP.

• SAML / OIDC SSO, MFA, Adaptive Auth
• Lifecycle Management - HR / HRIS to Okta to SaaS automated provisioning
• Workflows - no-code automation (BambooHR events create Slack and GitHub accounts automatically)
• Identity Governance - Access Certification, SoD, Access Requests

Customer Identity Cloud (CIC) is the customer-facing offering consolidated from the Auth0 acquisition. Essentially Auth0 rebranded under Okta.

The slot where 90 percent of enterprises adopt Okta is Workforce plus SaaS integration. Below 100 employees the price stings. Above several hundred, the value of SCIM and Workflows justifies it.

Chapter 16 - AWS Cognito: User Pools, Identity Pools, and the Deprecation Drama

AWS Cognito is AWS's native IdP. It has two slots.

The pros are clear. Within AWS it is nearly free to run, and AWS SDK and IAM integration is seamless.

The cons are equally clear. Between 2024 and 2025 Cognito deprecated and reorganized parts of its feature surface, prompting significant criticism. Two examples.

1. Custom Email Sender Lambda and parts of the SMS / MFA flow changed semantics.
2. Hosted UI has well-known gaps in OIDC standard compliance, including nonce validation and refresh token rotation behavior.

Another weak point is data export. There is no standard path to migrate a User Pool elsewhere with password hashes intact (it is possible, but only with custom Lambda triggers and a parallel migration flow). Cognito has earned the reputation of being easy to enter and hard to leave.

To choose Cognito for a new project, answer two questions clearly. (1) Will we live entirely inside AWS, and (2) can we tolerate the Hosted UI gaps.

Chapter 17 - Microsoft Entra ID: Formerly Azure AD, Plus External ID

Microsoft Entra ID (rebranded from Azure AD in 2023) is effectively the largest IdP in the world. Office 365, Microsoft 365, and Windows domains are all bound to it.

Headline features:

• Conditional Access - access policies driven by user, device, network, and risk that gate MFA or block sign-in.
• Privileged Identity Management (PIM) - just-in-time elevation of admin roles for a time-limited window.
• Identity Protection - risk-scored anomaly detection.
• Microsoft Authenticator plus Passkey support.

Entra External ID is the CIAM (customer IAM) service launched in 2024. The earlier Azure AD B2C is effectively spun off as a separate line and External ID is its successor.

The reason Entra is the enterprise default is licensing - it is bundled with Microsoft 365, which means SSO basics come free. The downside is deeper Microsoft lock-in in multi-cloud and multi-vendor environments.

Chapter 18 - Google Cloud Identity, Workspace SSO, and the New SaaS IdP Wave

Google Cloud Identity and Workspace SSO - Google becomes the IdP for your workplace domain. If you use Workspace, registering a SAML SP gives instant Google SSO.

The new SaaS IdP wave of the 2020s split into several niches.

The shared thread is developer experience as the headline differentiator. Console, SDK, components, and docs spin up faster than Auth0. The trade-off is shallower enterprise governance (Audit, Lifecycle, IGA) than what Okta or Entra ID provide.

Chapter 19 - Auth.js, Lucia, better-auth, Clerk: The Library Camp

Beyond managed and self-hosted IdPs, there is a direction of "building the IdP as code inside your framework."

Auth.js v5 (formerly NextAuth.js) was redesigned in 2024 and 2025 to fit the Next.js App Router. Over 70 OAuth / OIDC providers, many database adapters, and Edge runtime support.

// auth.config.ts - Auth.js v5 example
import NextAuth from "next-auth"
import GitHub from "next-auth/providers/github"

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [GitHub],
})

Lucia v3 is a headless session library. The 2024 v3 line strengthened the direction of "users write their own OAuth flow." A notable 2025 event was the maintainer announcing that Lucia would be repositioned as learning material rather than a library.

better-auth (better-auth.com) is a newer library that launched in 2024. It sits between Lucia's "write it yourself" and Auth.js's "framework integration." Its plugin architecture is strong.

Clerk is a managed SaaS, yet thanks to React / Next.js components (<SignIn />, <UserButton />) it feels library-shaped. Organizations, B2B multi-tenancy, Passkey, and Webhook are all well polished.

Selection guidance:

• Need a user directory and an admin console - managed (Clerk, Auth0) or self-hosted (Keycloak).
• Want to retain full code control - Auth.js or better-auth.
• Want to learn by writing it yourself - Lucia's documentation as study material.

Chapter 20 - The New Era of Authorization: OPA, OpenFGA, SpiceDB, Permify

One of 2026's bigger shifts is the separation of authentication and authorization. The IdP owns authentication, while a separate engine owns authorization.

OPA (Open Policy Agent, CNCF Graduated) writes policy in the Rego DSL.

package authz

default allow := false

allow if {
  input.user.role == "admin"
}

allow if {
  input.user.id == input.resource.owner
  input.action == "read"
}

OpenFGA (open-sourced by Auth0 in 2022, CNCF Sandbox) and SpiceDB (Authzed) are ReBAC (Relationship-Based Access Control) engines based on the Google Zanzibar paper.

The Zanzibar intuition is simple. Every permission is represented as a "user - relation - object" tuple.

# Zanzibar tuple example
user:alice    member        organization:acme
group:eng     member        organization:acme
user:bob      member        group:eng
document:doc1 viewer        group:eng

Can user:bob view document:doc1? Because bob is a member of eng and eng is a viewer of doc1, yes. Doing this graph traversal in milliseconds is the core job of a Zanzibar-style engine.

Permify is another open-source entry in the same direction. Written in Go, with an approachable schema DSL and support for several data stores.

The essence of this shift is lifting authorization out of application code. When permission logic is scattered through code, every change forces a redeploy and audit is difficult. Externalizing the engine turns policy itself into data and configuration.

Chapter 21 - The Korean and Japanese SSO Reality

Korea.

• Naver Cloud IAM - Naver Cloud's first-party IAM, can serve as a SAML 2.0 IdP.
• Kakao i Identity - the enterprise IAM / SSO from Kakao Enterprise.
• KT Cloud SSO - KT's SAML / OIDC IdP, with many public-sector and financial customers.
• SK ICT-IAM - the standardization push for IAM across the SK group.
• Government GovWAY and GPKI - the SSO and certificate framework for public agencies.
• Private financial certificates, Toss Auth, PASS - identity verification tools. Different in nature from SSO, but they bind to KYC stages.

In the enterprise space Okta and Entra ID have moved in through large firms, while Keycloak and Authentik occupy the self-hosted slots at mid-market and startup companies. There is also a clear trend of Korean clouds like NHN Cloud and Kakao i strengthening their own SSO offerings.

Japan.

• Trust IdP (National Institute of Informatics, NII) - SAML federation for academic and research institutions.
• Cybozu Office and Cybozu KUNAI - Cybozu's enterprise SSO.
• NTT Communications IDPro - NTT's managed IdP.
• OpenAM (the ForgeRock open-source fork) - actively maintained by the Japanese OSS community.
• TrustLogin (GMO) - a Japanese SaaS SSO aggregator.
• HENNGE One - a Japanese-market SSO and email security solution with deep integrations into Japan-local SaaS.

The Japanese market still carries a thick ForgeRock (OpenAM) heritage, and a large share of organizations use Microsoft 365 or Google Workspace as the IdP directly. HENNGE One enjoys success because of its rich SAML adapter set for Japan-local SaaS, making it the default for "companies that do not want to install an IdP themselves."

Chapter 22 - Migrations and Lock-In: Lessons from ForgeRock, Auth0, Cognito

ForgeRock to Ping Identity - in August 2023 Thoma Bravo closed the ForgeRock acquisition and aligned it with Ping Identity onto a unified roadmap. Subsequent feature consolidations or absorptions into Ping equivalents made migration cost visible to existing customers.

Auth0 lock-in - as discussed earlier, the deeper the dependence on Actions, Rules, and Custom DB Actions, the harder leaving becomes. Typical migration strategies include (1) double-writing from Auth0 to Keycloak or Clerk and cutting over gradually, and (2) varying the flow based on whether password-hash export is possible.

AWS Cognito feature deprecation - the changes between 2024 and 2025 hurt user trust. New projects increasingly limit Cognito to the slot of "AWS-only scenario plus simple user directory" and reach for other IdPs when sophisticated flows are needed.

Keycloak 18 to 26 migration - the shift from WildFly to Quarkus was a large change. Moving from 18.x or below to 26.x required (1) automatic DB schema migration, (2) the new build step (kc.sh build), and (3) handling some SPI interface signature changes. Settling on 26.0 or 26.1 in the LTS cycle is the standard recommendation.

Three general migration principles.

1. Stay on top of standards - prefer OIDC, SAML, and SCIM over IdP-native features.
2. Choose IdPs with a password-hash export path. The ones without are effectively lock-in.
3. Stream events to an external SIEM. Even if you change IdPs, your audit trail survives.

Conclusion - An IdP Is a Lifecycle, Not a Selection

This article spans 22 chapters, but it compresses to one line.

"If you cannot manage authentication, authorization, provisioning, and audit as one lifecycle, no IdP you install will be more than a partial solution."

Recommended starting points for small teams.

• Managed and fast - Clerk or Auth0 (price tolerable).
• Self-hosted with governance - Keycloak 26 on a single node plus Postgres.
• Self-hosted with modern UI - Authentik.
• Reverse-proxy gateway - Authelia.
• Separated authorization - OpenFGA or SpiceDB.
• Library-first - Auth.js v5 or better-auth.

Recommended starting points for the enterprise.

• Employee-facing - Okta WIC or Entra ID (leverage licensing).
• Customer-facing - Auth0, Okta CIC, or Keycloak multi-tenant.
• HR to IdP to SaaS automated provisioning - Okta Lifecycle or Workato / Tray plus SCIM.
• Policy engine - OPA or SpiceDB as the external authorizer.

Tools change. Standards change slowly, lifecycles barely change at all. So design the standards and lifecycle first and place the tools on top.

References

• Keycloak Documentation
• Keycloak 26 Release Notes
• Red Hat build of Keycloak
• Authentik Documentation
• Authelia Documentation
• Casdoor Documentation
• Ory Documentation
• Logto Documentation
• Auth0 Documentation
• Okta Developer Documentation
• AWS Cognito Developer Guide
• Microsoft Entra ID Documentation
• Microsoft Entra External ID Overview
• OAuth 2.1 Draft
• OAuth Security BCP
• OpenID Connect Core 1.0
• WebAuthn Level 3 (W3C)
• FIDO Alliance Specifications
• SCIM 2.0 RFC 7644
• SAML 2.0 OASIS Standard
• Open Policy Agent
• OpenFGA Documentation
• Authzed SpiceDB
• Permify Documentation
• Auth.js v5 Documentation
• Lucia Auth
• better-auth Documentation
• Clerk Documentation
• HENNGE One
• Naver Cloud IAM