Keycloak vs Authentik vs Zitadel vs Ory Hydra vs Auth0 vs WorkOS vs Okta — 2026 SSO / OIDC / SAML / OAuth 2.1 / FAPI 2.0 / FedCM Deep Dive

Cold open — why SSO is sharp again in May 2026

In Q1 2026, the IETF finalized OAuth 2.1 as an official RFC. In the same quarter, the OpenID Foundation marked FAPI 2.0 Security Profile as Final. In May, Chrome's stable channel turned on FedCM (Federated Credential Management) by default across desktop and mobile. Microsoft Edge followed a month later. At the same time, NIST published SP 800-63-4, naming passkeys and syncable authenticators as default AAL2 recommendations.

All of that happened inside a single quarter. So in 2026 the SSO question is no longer "do we buy Okta or self-host?" — that was a 2021 question. The real questions today are: (1) which protocol stack do we adopt, (2) do we let the browser broker federation for us, and (3) how do we serve passkey-only consumers and SAML-required enterprises in the same product.

Cast of characters — who plays which role

The seven IdPs compared here do not fight in the same market. They share vocabulary but occupy different positions.

Product	License	Hosting	Strength	Weakness
Keycloak	Apache 2.0	Self-hosted	Quarkus startup, deep adapters	Multi-tenancy thin, UI rough
Authentik	MIT	Self-hosted	Outpost model, modern UI	Smaller community
Zitadel	Apache 2.0	Self-hosted / SaaS	Multi-tenant, event sourcing	Operational learning curve
Ory Hydra	Apache 2.0	Headless	OAuth 2.1 conformance, light	No UI, you build it
Auth0	Commercial	SaaS	DX, Rules/Actions	Post-Okta pricing
WorkOS	Commercial	SaaS	B2B SSO/SCIM only	Weak for B2C
Okta	Commercial	SaaS	Enterprise standard	Price, incident history

This table is only the starting point. Real selection depends on user volume, multi-tenancy need, regulated industry, and most importantly the operating team's capacity.

OAuth 2.1 versus 2.0 — what actually changed

OAuth 2.1 was finalized as RFC 9700-series in January 2026. The headline changes are not new inventions; they promote a decade of best-practice BCPs into hard requirements.

The implicit grant is removed. More IdPs are dropping response_type=token outright.
Resource Owner Password Credentials grant is removed. Keycloak 25 disables it by default; an explicit feature flag is required.
PKCE is mandatory for all clients, confidential included. The old "public clients only" carve-out is gone.
Refresh-token rotation moved from recommendation to de-facto requirement.
Redirect-URI matching must be exact. No wildcard prefix matching.

The biggest friction in deploying OAuth 2.1 is mobile apps and SPAs. Without implicit, you must use Authorization Code + PKCE — which forces you to decide on a backend-for-frontend pattern or native secure storage (iOS Keychain, Android Keystore) for refresh-token custody.

DPoP and sender-constrained tokens — why token theft hurts less

DPoP (Demonstration of Proof-of-Possession, RFC 9449) addresses the worst property of bearer tokens: once stolen, always usable. With DPoP, the client must present the token together with a JWT (the DPoP proof) signed by the client's private key. The resource server compares the cnf.jkt claim in the token to the proof's public key.

Before DPoP, the canonical attack chain was:

XSS lifts an access token out of the SPA.
The attacker calls the API server directly with that token.
The server validates the token only, so the call goes through.

DPoP breaks step 3. The token is useless without the matching private key. Combined with WebCrypto's non-extractable key storage, it becomes hard to lift the key out of the SPA at all.

As of May 2026, DPoP is supported out of the box by Keycloak 25, Zitadel, and Ory Hydra. Auth0 has it in beta on enterprise plans, Okta supports it on selected workflows, and Authentik stabilized it in the December 2025 release.

FAPI 2.0 — the new floor for financial APIs

FAPI (Financial-grade API) 1.0 Advanced has been in use since 2018 in UK Open Banking. FAPI 2.0 distills that experience into a simpler profile.

Key differences:

The response-signing requirements of FAPI 1.0 (JARM and friends) are simplified.
Either mTLS or DPoP — but only sender-constrained tokens are accepted.
PAR (Pushed Authorization Request, RFC 9126) is mandatory: the authorization request is pushed back-channel first, and only a short request_uri is sent through the front channel.
RAR (Rich Authorization Requests, RFC 9396) is standardized, allowing transaction-grained authorizations like "approve a transfer of KRW 10,000,000."

Korea Mydata, Japan's e-government APIs, and EU PSD3 are all converging on FAPI 2.0 as a baseline. Keycloak passed FAPI 2.0 conformance in 2025. Authelia is not compliant. Auth0 supports it through an add-on profile.

Keycloak 25 — life after the Quarkus migration

Keycloak switched from WildFly to Quarkus in v18 and has been stabilizing that decision through v25. Cold start is now sub-second. Memory footprint is roughly half. Container images are small enough that HPA in Kubernetes works without surprises.

What's new in 25:

Account Console v2 was rewritten in React, improving the passkey-registration UX.
The Admin UI got the same React rewrite; the REST API is stable.
Organizations graduated to GA. It is not true multi-tenancy, but it lets you group users by org within a single realm.
WebAuthn passwordless registration is now integrated into the default authentication flow.

# Keycloak 25 deployment in Kubernetes (Helm values, excerpt)
keycloak:
  image:
    repository: quay.io/keycloak/keycloak
    tag: "25.0.6"
  args:
    - "start"
    - "--optimized"
    - "--db=postgres"
    - "--hostname=auth.example.com"
    - "--proxy-headers=xforwarded"
    - "--health-enabled=true"
    - "--metrics-enabled=true"
  env:
    - name: KC_FEATURES
      value: "fapi,dpop,par,organization,passkeys"
    - name: KC_LOG_LEVEL
      value: "INFO"
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      memory: 2Gi

What Keycloak still does badly is multi-tenant SaaS. Running a realm per tenant inflates instance count. Running hundreds of realms in one instance slows cold start again. That is precisely where Zitadel enters the picture.

Authentik — what the Outpost model buys you

Authentik started as a proxy-authentication tool and grew into a full IdP. The defining concept is the Outpost: a separate, small process that lives outside the IdP core. Each Outpost owns a single protocol — LDAP, RADIUS, or Proxy.

What Outposts buy you:

A crashed LDAP server doesn't take down OIDC.
Outposts deploy via a Kubernetes operator with sane defaults.
The security boundary is cleaner: Outposts never touch the IdP DB directly, only the API.

Authentik's Flow concept is also worth a careful read. Authentication, registration, password reset — all expressed as the same "Flow" abstraction, composing Stages (MFA, password, prompt, captcha, etc.) to build an arbitrary user journey.

# Authentik flow example: passkey first, TOTP fallback
metadata:
  name: default-authentication-flow
spec:
  designation: authentication
  stages:
    - name: identification
      type: identification
      user_fields: [email, username]
    - name: webauthn-passkey
      type: authenticator_validate
      device_classes: [webauthn]
      not_configured_action: skip
    - name: password-fallback
      type: password
      backends: [authentik_core.auth.InbuiltBackend]
    - name: totp-mfa
      type: authenticator_validate
      device_classes: [totp]
      not_configured_action: configure

Authentik's weak spots are community size and enterprise support. BeryJu the company sells commercial licenses, but Okta-grade SLAs are not on the menu.

Zitadel — multi-tenancy as a first-class design

Zitadel is a Swiss-built IdP designed from day one for multi-tenant SaaS. What sets it apart structurally is event sourcing plus CQRS at the core.

Every state change is stored as an event. User creation, password change, permission grant, token issuance — all written to an append-only event log. The current state is built as projections (materialized views). The consequences:

Every change is permanently auditable. Audit requirements get easier.
Read models can be reshaped — move a PostgreSQL projection into ClickHouse if you need analytics shapes.
You can "rewind" a user — track a bad permission change event by event and reverse it surgically.

Multi-tenancy in Zitadel runs through the Organization unit. A single instance can host thousands of Organizations, each with its own IdP settings, custom domain, and branding. Operating a thousand Keycloak realms versus a thousand Zitadel Organizations is an order-of-magnitude difference in ops cost.

The cost is operational learning curve. You need CockroachDB-compatible PostgreSQL, and the event log grows quickly, so retention policy must be deliberate.

Ory Hydra — a headless OAuth 2.1 server

Ory Hydra targets one thing: OIDC / OAuth 2.1 specification conformance. It has no UI. No user database. No login page. All of that is delegated to a "consent app" you supply.

The flow looks like:

The client sends the user to /oauth2/auth.
Hydra redirects, not to itself, but to your separately hosted login app.
The login app authenticates the user and tells Hydra "accept this subject."
Hydra redirects to the consent step.
After the same pattern repeats for consent, Hydra issues tokens.

// Ory Hydra login app example (Express)
import express from 'express'
import { Configuration, OAuth2Api } from '@ory/client'

const hydraAdmin = new OAuth2Api(
  new Configuration({ basePath: process.env.HYDRA_ADMIN_URL })
)

const app = express()

app.get('/login', async (req, res) => {
  const challenge = req.query.login_challenge as string
  const { data: loginRequest } = await hydraAdmin.getOAuth2LoginRequest({
    loginChallenge: challenge,
  })

  // Your own authentication logic (passkey, password, MFA...)
  // ...
  const subject = 'user-uuid-1234'

  const { data: accept } = await hydraAdmin.acceptOAuth2LoginRequest({
    loginChallenge: challenge,
    acceptOAuth2LoginRequest: {
      subject,
      remember: true,
      remember_for: 3600,
    },
  })

  res.redirect(accept.redirect_to)
})

Hydra fits cleanly when your company already owns the user database and the login UI and only needs to bolt OIDC/OAuth onto the front. Hydra does not fit the "we just need an IdP" case — for that, Keycloak or Zitadel get you to a working system much faster.

Auth0 — four years into the Okta era

Okta acquired Auth0 in 2021. Four years later, in 2026, the two products clearly serve different markets.

Auth0 = developer-friendly, B2C, fast integration, the Rules-to-Actions migration is complete.
Okta Workforce = enterprise SSO, Universal Directory, Lifecycle Management.
Okta Customer Identity Cloud = Auth0 rebranded plus enterprise sales motion.

Auth0 pricing climbed sharply between 2024 and 2025. The free tier shrank, and per-MAU pricing got steeper. Multiple public case studies report the bill at 1 M MAU rising roughly 2.5x compared to 2021 levels. That is the underlying reason self-hosted IdP migrations are trending again.

What Auth0 still does well is developer experience. SDK quality, documentation, support — self-hosted options have not closed this gap. For early-stage startups and fast PoCs, Auth0 is still a reasonable bet.

WorkOS — a product aimed only at B2B

WorkOS is a SaaS built to answer one question: "How do we onboard an enterprise customer demanding SSO, fast?" The core value proposition:

Unified API for SAML, OIDC, and SCIM.
"Directory Sync" — over thirty directories (Okta, Azure AD, Google Workspace, BambooHR, etc.) collapsed into one model.
It does not do B2C. Consumer signups, password reset, identity recovery go elsewhere.

When WorkOS fits:

You already have your own authentication for end users.
An enterprise customer now demands "we need Okta SSO."
You don't want to learn how each IdP exchanges SAML metadata differently.

In that scenario WorkOS unifies the integration behind a single endpoint. Auth0 can also do this, but WorkOS is cheaper and simpler precisely because that is the only thing it does.

Okta in 2026 — rebuilding trust after the incidents

Okta survived the Lapsus$ incident in 2022 and the HAR-file leak in 2023. By 2026 the company has substantially rebuilt its security governance and migrated all customers to OIE (Okta Identity Engine). Even so, some enterprises now run a backup IdP precisely because of "single-vendor risk."

Okta's strengths are unchanged:

Over seven thousand pre-built integrations (the Okta Integration Network).
Lifecycle Management — HR system changes propagate directly into entitlements.
Adaptive MFA — risk scoring across device, location, and behavior.

Weaknesses are price, lock-in, and the fact that if Okta goes down, your company does too. The mitigation pattern that became common after 2022 is a runbook entry: "If Okta is down, here is the backup login path."

FedCM — the browser brokers federation

FedCM makes identity federation work without third-party cookies. The old "Sign in with Google" buttons relied on third-party iframes and redirects. In a world without third-party cookies, those flows break.

How FedCM works:

The RP (Relying Party) calls navigator.credentials.get({ identity: { providers: [...] } }).
The browser fetches the IdP's manifest.
The browser shows a native, system-rendered dialog: "This site wants to sign you in with your account at X.com."
On user consent, the browser fetches the ID token from the IdP and hands it back to the RP.

# FedCM IdP manifest example
GET /.well-known/web-identity HTTP/1.1
Host: idp.example.com

HTTP/1.1 200 OK
Content-Type: application/json

{
  "accounts_endpoint": "/fedcm/accounts",
  "client_metadata_endpoint": "/fedcm/client_metadata",
  "id_assertion_endpoint": "/fedcm/assertion",
  "login_url": "/login",
  "branding": {
    "background_color": "#0f172a",
    "color": "#ffffff",
    "icons": [{ "url": "https://idp.example.com/icon.png", "size": 64 }]
  }
}

FedCM is stable in Chrome since 132 and shipped with the same surface in Edge 132. Safari is "considering" as of May 2026. Keycloak 25 ships an experimental FedCM IdP endpoint. Zitadel has announced first-class support. Auth0 and Okta lead with RP-side SDKs.

Passkeys and WebAuthn — no longer "new tech"

Passkey adoption hit an inflection point in 2026. Roughly thirty percent of Microsoft accounts use passkeys. Apple iCloud Keychain effectively enables passkey sync for every iOS user. Google accounts trend similarly.

Things to mind when implementing passkeys at the IdP level:

Resident keys (discoverable credentials) differ from non-resident keys. Passkeys are resident keys.
Cross-device authentication (CDA, hybrid transport) is what lets a desktop browser use a phone-resident passkey.
Define an attestation policy. Enterprises typically require packed attestation.
Account recovery if a passkey is lost — get this wrong and users will be stranded.

Keycloak 25 has passkey registration built into the default flow. Authentik's WebAuthn stage is GA. Zitadel has been WebAuthn first-class from day one. Ory delegates this to Kratos, not Hydra. Auth0 offers passkey options inside "Universal Login."

SCIM and JIT provisioning

Enterprise customers almost always demand SCIM (System for Cross-domain Identity Management). When a user is added to the HR system, your service should auto-provision; when a user is disabled in HR, your service should lock them out immediately.

SCIM 2.0 standard endpoints:

/scim/v2/Users — user CRUD
/scim/v2/Groups — group CRUD
/scim/v2/Bulk — bulk changes
/scim/v2/ServiceProviderConfig — your advertised SCIM options

The trap with SCIM is the ambiguity of the spec. Mapping of userName to emails[].value, direction of group-membership sync (IdP push versus SP pull), soft delete versus hard delete — every IdP makes slightly different choices. WorkOS hides this and exposes a single API. That is what you are buying.

JIT (Just-In-Time) provisioning is the lightweight alternative. On the first login, the IdP creates the user record from the claims in the SAML/OIDC assertion. Fast to ship, but it cannot do immediate deprovisioning.

Identity broker patterns — integrating Korea PASS and Japan JPKI

In Korea, identity verification for KYC and Mydata flows through "본인확인기관" (identity-verification agencies) like PASS, KakaoPay, Naver, and Toss — not through general-purpose IdPs. In Japan, JPKI (Japanese Public Key Infrastructure) on top of the マイナンバーカード is the government's authentication standard.

Integrating these directly into your service means you handle a different protocol, response format, and renewal cadence for each. The identity broker pattern lets your IdP take responsibility for that integration.

Keycloak Identity Providers, Zitadel External IdPs, and Auth0 Custom Connections all support this pattern. In Korea, the typical mapping is:

PASS API → adapter onto an IdP custom OIDC provider
Kakao sync → registered as an OAuth 2.0 provider in the IdP
Naver → OAuth 2.0 provider in the IdP
Identity verification (KISA-certified) → custom SAML or custom provider

JPKI is more involved. It needs PIN entry, card reader integration, and the JPKI client app. The IdP usually standardizes only the interface to the JPKI client; the actual card communication happens on the user device.

B2B vs B2C — can one IdP do both

In B2C, users sign up with their own email and log in with their own passkey. The company doesn't own those credentials.

In B2B, users sign up with their company email. The company runs SSO, and users reach your service through the company's IdP. Permissions are managed by the company.

Can one IdP handle both? Technically yes; recommended no. The user model, authentication flow, and authorization model differ enough that the merged shape is worse than either alternative. The pattern that works:

Start B2C on Auth0, Cognito, or a homegrown solution.
First enterprise customer demands SSO. Add WorkOS to absorb SAML.
As users grow, migrate to a self-hosted IdP (Keycloak / Zitadel).
At that migration point, split B2B and B2C tenants.

Planning for this evolution from day one keeps migration cost small. Cramming everything into one IdP and disentangling later is much more expensive.

MFA evolution — SMS is dead, passkeys are the standard

NIST SP 800-63-4 removed SMS OTP from recommended AAL2 authenticators. SS7 attacks and SIM swap attacks make SMS unsafe. Many services still use SMS OTP in 2026 for one reason: "users do not want to install another app."

Alternatives:

Passkeys — most secure. Recovery on device loss is the hard part.
TOTP (Google Authenticator, Aegis) — still a reasonable MFA.
Push notification (Authy, Duo) — safe when used with phishing-resistant mode.
Hardware keys (YubiKey) — enterprise standard, but backup key needed on loss.

MFA policy at the IdP must be risk-based. Requiring MFA on every single login pushes users to build workarounds (permanent cookies, "remember me forever"). Reasonable is "MFA on new device, new IP, or right before a sensitive action."

Session management and token revocation

One of the harder parts of OIDC is the "user logs out everywhere" story — front-channel logout and back-channel logout are specified but unevenly implemented across IdPs.

Token revocation matters more under OAuth 2.1. Scenario:

The user's phone is stolen.
Corporate IT terminates all sessions for that user at the IdP.
Already-issued access tokens stay valid until expiry, usually 5-60 minutes.

To shrink that 5-60 minute window:

Keep access-token lifetimes short (under five minutes). Traffic goes up, safety goes up.
Use token introspection (RFC 7662) on every API call. Expensive but revocation is instant.
Or cache a revocation list — a sliding cache reflects new revocations quickly.

Keycloak, Zitadel, and Auth0 all expose an introspection endpoint. Ory Hydra goes lighter, mixing self-contained validation with introspection.

The actual cost of self-hosted IdPs

"Open-source IdPs are free" only looks at the license. The real cost stack:

HA operations: PostgreSQL primary plus replicas, three or more IdP instances, load balancer, certificate rotation.
Backup and restore drills.
Security patch tracking — CVE response within 24 hours when one lands.
24/7 on-call. From the user's perspective, your IdP being down is identical to Okta being down.
Compliance audits. If you carry SOC 2 Type II, your IdP is in audit scope.

A rough back-of-envelope at one million MAU:

Auth0 / Okta CIC: USD 20,000-30,000 per month.
Self-hosted Keycloak or Zitadel: USD 1,000-3,000/month infra plus half to one full-time engineer.

The break-even depends on your size and operating capacity. Below 300k users, SaaS is almost always cheaper. Above 2M, self-hosting almost always is.

Attack surface — token theft, refresh rotation, OAuth phishing

OAuth-adjacent attack trends from 2025-2026:

OAuth phishing — fake client IDs that pass through the real IdP consent screen and trick users into granting permissions. Google and Microsoft are responding with stricter application verification.
Refresh-token replay — without rotation, a single stolen refresh token enables indefinite re-issue. RFC 6749 4.1.4 marks rotation as SHOULD, but 2026 treats it close to MUST.
Token theft via a malicious browser extension — the extension reads tokens from SPA memory. DPoP plus non-extractable WebCrypto keys mitigates this.
Open-redirector chains — lax redirect_uri validation in the RP leaks tokens to an attacker domain. OAuth 2.1's exact-match requirement closes most of this.

Operating an IdP means blocking these classes at the IdP layer and exposing safe SDKs to RP developers.

Enterprise SSO procurement reality — SAML will not die

Startup engineers ask, "Why are we still on SAML?" Answer: because enterprises require it.

From the enterprise IT perspective:

SAML has twenty years of operational experience. Debugging tools, known traps, and standard metadata-exchange procedures are all settled.
OIDC is relatively new, and each IdP implements it slightly differently.
Security review boards treat SAML as the "safe default."

So if you want enterprise customers, your service must support both OIDC and SAML. WorkOS, Auth0, Okta CIC, Keycloak, and Zitadel all support both, but implementation quality and metadata-exchange automation vary widely.

Common procurement requirements you will face:

A discoverable SAML metadata URL.
AuthnRequest signing options.
SLO (Single Logout) support.
IdP-initiated SSO support (a known risk, but enterprises ask anyway).
Group mapping (Active Directory group → service role).

Korea-specific context — PASS, KISA, identity verification

If you run SaaS in Korea, the identity requirements you will meet:

본인인증 — identity verification keyed on RRN (Resident Registration Number). Must go through a KISA-certified identity-verification agency (NICE, KCB, SCI).
PASS — a unified authentication app run by the three telcos; the main delivery channel for 본인인증.
Mydata — financial data portability, built on FAPI 1.0 Advanced.
Since the 2020 Electronic Signature Act revision, the old "public certificate" monopoly is gone, and various private certificate schemes are recognized.

When integrating 본인인증 with your own IdP:

Store the verification result on the IdP user profile. The RRN itself must be hashed (legal requirement).
CI (Connecting Information) and DI (Duplicate Information) mean different things — CI identifies the same person across services, DI prevents duplicate sign-ups in one service.
Treat the validity window of a verification result (usually six months to one year) as policy.

Japan-specific context — JPKI, My Number, OIDC for Identity Assurance

Japan's government authentication standard is JPKI built on top of the マイナンバーカード (My Number Card). The card carries two certificates: one for signing and one for user identification.

Service integration notes:

The "JPKI user-identification certificate" enables OIDC login with a 4-digit PIN.
The "JPKI signing certificate" supports proper electronic signatures with a 6-16 character PIN.
The マイナンバー (personal number) itself must never be stored at the IdP — that violates the My Number Act.

OIDC for Identity Assurance (OIDC4IDA) is a spec in which Japan participates standardization. It lets the IdP convey the user's Level of Assurance to the RP. A JPKI-integrated IdP uses OIDC4IDA's verified_claims to communicate "this user completed identity verification via the My Number Card" reliably.

# OIDC4IDA response example (excerpt)
{
  "sub": "user-uuid-9876",
  "verified_claims": {
    "verification": {
      "trust_framework": "jp_aml",
      "assurance_level": "high",
      "evidence": [{
        "type": "electronic_record",
        "check_details": [{
          "check_method": "kbv",
          "organization": "JPKI",
          "txn": "tx-2026-05-001"
        }]
      }]
    },
    "claims": {
      "given_name": "Taro",
      "family_name": "Yamada",
      "birthdate": "1985-04-12"
    }
  }
}

Migration scenario — moving from Auth0 to Keycloak

A common path in 2026: a team starts on Auth0, watches the bill climb, and migrates to a self-hosted IdP.

Migration checklist:

Export user data — use the Auth0 Management API to dump users and metadata. bcrypt password hashes can be imported as-is; non-bcrypt hashes require a reset email to users.
Application/client mapping — Auth0 Application = Keycloak Client. Redirect URIs, allowed origins, grant types move 1:1.
Rules/Actions migration — Auth0's JavaScript hooks must be reimplemented as Keycloak Authenticator SPI or Event Listener SPI. There is no automatic migration tool.
Connections (social IdPs) — re-register Google, GitHub, Apple, etc. OAuth client IDs/secrets as Keycloak Identity Providers.
Cut-over without downtime — synchronize the user set in both systems before the DNS swap. Either incremental migration or a dual-write window is standard.

What breaks most often in the middle of migration: password-hash algorithm mismatch and user_id format changes that cascade through external references.

Conclusion — a 2026 decision tree

This is a long piece, but the decision is simple in shape.

Under 300k users, light ops team → Auth0 or Okta CIC.
B2B only, enterprise SSO/SCIM is the entire concern → WorkOS.
Self-host viable, single tenancy is enough → Keycloak 25.
Self-host needed, true multi-tenant SaaS → Zitadel.
You already have your own user DB and only need OIDC → Ory Hydra.
Proxy authentication, lighter use cases → Authentik.
Large enterprise, you need the 7000-integration network → Okta Workforce.

After the pick, verify the following without fail:

OAuth 2.1 conformance (mandatory PKCE, implicit refusal, refresh rotation).
DPoP or mTLS support.
FAPI 2.0 certification if your industry needs it.
FedCM IdP endpoint roadmap.
Completeness of the passkey enrollment / use / recovery flow.
SCIM 2.0 in both directions.
Local integration (Korea PASS, Japan JPKI) possibility.

SSO in 2026 is no longer a "login box." It is the infrastructure component that handles the full identity lifecycle, device binding, regulatory fit, and browser-brokered federation simultaneously. A well-chosen IdP lasts five years. A poorly chosen one burns a year of engineering on migration.