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.

| Layer | Problem | How SSO answers |

| --- | --- | --- |

| Identity | How many copies of one person exist in the company | A single user object, a single ID |

| Account | Are 50 passwords alive across 50 SaaS apps | Federated login, just-in-time provisioning |

| Session | If a laptop is stolen, can you log out everywhere at once | Central session, Single Logout (SLO) |

| Audit | Who accessed what, when, and from where | Central event log, SIEM integration |

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.

| Standard | What it does | Where it shows up |

| --- | --- | --- |

| OAuth 2.1 | Delegated authorization for APIs | API calls, mobile apps, SPAs |

| OpenID Connect (OIDC) | Identity layer on top of OAuth | Web and mobile user login |

| SAML 2.0 | XML-based enterprise SSO | Legacy SaaS, Workday, Salesforce |

| SCIM 2.0 | User and group provisioning | Okta to Slack, Entra to Zoom |

| WebAuthn / FIDO2 | Strong passwordless authentication | Passkeys, YubiKey, Touch ID |

**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 -->

alice@example.com

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:

| Endpoint | Purpose |

| --- | --- |

| /Users | User CRUD |

| /Groups | Group CRUD |

| /Schemas | Schema metadata |

| /ServiceProviderConfig | Which features are supported |

| /Bulk | Bulk updates |

{

"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.

| Word | Meaning |

| --- | --- |

| Realm | Isolated user and client space, usually per environment or tenant |

| Client | An app that delegates authentication (web, mobile, service account) |

| Identity Provider | An external IdP that Keycloak delegates to (Google, GitHub, SAML IdP) |

| User Federation | An existing directory like LDAP / AD pulled in as the user source |

| Roles | Permissions scoped to the realm or to a client |

| Groups | User groupings, can inherit roles and attributes |

| Authentication Flow | The scenario of login steps (browser, direct, reset, and so on) |

| Theme | Customization unit for HTML / CSS / JS (login, account, admin, email) |

**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.

| Component | Role |

| --- | --- |

| Kratos | Sign-up / login / recovery / MFA (Identity) |

| Hydra | OAuth 2.0 / OIDC server |

| Keto | ReBAC (Zanzibar) authorization |

| Oathkeeper | Policy-driven reverse proxy |

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.

| Component | Role |

| --- | --- |

| User Pools | OIDC-compatible IdP - user directory plus login |

| Identity Pools | Issues AWS credentials - STS tokens for direct S3 / DynamoDB access |

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.

| Product | Slot | Notable trait |

| --- | --- | --- |

| Stytch | API-first auth | Strong SDK, Magic Link, Passwordless |

| FusionAuth | Self-hostable | Single binary, clear pricing |

| WorkOS | B2B SSO gateway | Delegate SAML / OIDC adapters |

| Frontegg | B2B multi-tenancy | UI, Org, SCIM packaged |

| Clerk | React / Next.js friendly | Polished SDK and components |

| Logto | Open source plus managed | Developer experience first |

| SuperTokens | Self-hosting focused | OAuth and session token modes |

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

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](https://www.keycloak.org/documentation)

- [Keycloak 26 Release Notes](https://www.keycloak.org/2024/10/keycloak-2600-released)

- [Red Hat build of Keycloak](https://access.redhat.com/products/red-hat-build-of-keycloak)

- [Authentik Documentation](https://docs.goauthentik.io/)

- [Authelia Documentation](https://www.authelia.com/)

- [Casdoor Documentation](https://casdoor.org/docs/overview)

- [Ory Documentation](https://www.ory.sh/docs/)

- [Logto Documentation](https://docs.logto.io/)

- [Auth0 Documentation](https://auth0.com/docs)

- [Okta Developer Documentation](https://developer.okta.com/docs/)

- [AWS Cognito Developer Guide](https://docs.aws.amazon.com/cognito/latest/developerguide/)

- [Microsoft Entra ID Documentation](https://learn.microsoft.com/en-us/entra/identity/)

- [Microsoft Entra External ID Overview](https://learn.microsoft.com/en-us/entra/external-id/external-identities-overview)

- [OAuth 2.1 Draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)

- [OAuth Security BCP](https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/)

- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)

- [WebAuthn Level 3 (W3C)](https://www.w3.org/TR/webauthn-3/)

- [FIDO Alliance Specifications](https://fidoalliance.org/specifications/)

- [SCIM 2.0 RFC 7644](https://www.rfc-editor.org/rfc/rfc7644)

- [SAML 2.0 OASIS Standard](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

- [Open Policy Agent](https://www.openpolicyagent.org/)

- [OpenFGA Documentation](https://openfga.dev/docs)

- [Authzed SpiceDB](https://authzed.com/docs)

- [Permify Documentation](https://docs.permify.co/)

- [Auth.js v5 Documentation](https://authjs.dev/)

- [Lucia Auth](https://lucia-auth.com/)

- [better-auth Documentation](https://www.better-auth.com/docs/introduction)

- [Clerk Documentation](https://clerk.com/docs)

- [HENNGE One](https://hennge.com/global/products/hennge-one/)

- [Naver Cloud IAM](https://www.ncloud.com/product/management/iam)