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 徹底比較

コールドオープン — 2026年5月、SSO がふたたび先鋭化した理由

2026年第1四半期、IETF は OAuth 2.1 を正式な RFC として確定させた。同じ四半期に OpenID Foundation は FAPI 2.0 Security Profile を Final とした。5月、Google Chrome の安定版チャネルは FedCM(Federated Credential Management)API をデスクトップ・モバイル全体で既定有効化した。Microsoft Edge は1か月遅れで同じインタフェースを揃える。同時期、NIST は SP 800-63-4 を発行し、パスキーと同期可能な認証器(syncable authenticator)を AAL2 の既定推奨として明示した。

これらすべてが1四半期の内に重なった。だから2026年の SSO は「Okta を買うか、自前で立てるか」という5年前の問いとは異なる。今の焦点は (1) どのプロトコルスタックを採るか、(2) ブラウザがフェデレーションを仲介するのを受け入れるか、(3) パスキー専用ユーザと SAML しか受け付けないエンタープライズ顧客を同一プロダクトでどう捌くか、である。

登場人物の整理 — 誰がどのポジションにいるか

本稿で比較する7つの IdP は、同じ市場で戦っていない。語彙は似ているが、実際のポジションは違う。

製品	ライセンス	ホスティング	強み	弱み
Keycloak	Apache 2.0	セルフホスト	Quarkus による高速起動、豊富なアダプタ	マルチテナンシ薄、UI 粗
Authentik	MIT	セルフホスト	Outpost モデル、モダン UI	コミュニティ小
Zitadel	Apache 2.0	セルフホスト / SaaS	マルチテナント、イベントソーシング	運用学習曲線
Ory Hydra	Apache 2.0	ヘッドレス	OAuth 2.1 適合性、軽量	UI 無、自作必要
Auth0	商用	SaaS	DX、Rules/Actions	Okta 買収後の価格
WorkOS	商用	SaaS	B2B SSO/SCIM 特化	B2C には弱い
Okta	商用	SaaS	エンタープライズ標準	価格、インシデント履歴

この表は出発点にすぎない。実際の選定はユーザ規模、マルチテナンシ要件、規制業種、そして何より運用チームの能力に依存する。

OAuth 2.1 と OAuth 2.0 の違いを改めて

OAuth 2.1 は2026年1月、RFC 9700番台として確定した。中核となる変更は新しい発明ではなく、過去10年のベストプラクティスを強制要件まで引き上げたものだ。

Implicit grant は撤廃。response_type=token を完全に切る IdP が増えている。
Resource Owner Password Credentials grant も撤廃。Keycloak 25 は既定無効、明示的なフラグが必要。
PKCE はすべての client、confidential を含めて必須。「public client のみ」という例外はもうない。
Refresh token rotation は推奨から事実上の必須へ昇格。
Redirect URI のマッチングは exact match のみ。wildcard prefix は禁止。

OAuth 2.1 を実システムに導入するときの最大の摩擦はモバイルアプリと SPA で起きる。Implicit が消えたので Authorization Code + PKCE しか選べない。となればモバイルアプリでは backend-for-frontend(BFF)パターンか、native secure storage(iOS Keychain、Android Keystore)を使った refresh token 管理を併せて決める必要がある。

DPoP と sender-constrained トークン — トークン盗難が致命傷でなくなる理由

DPoP(Demonstration of Proof-of-Possession、RFC 9449)は OAuth bearer token の最大の弱点「盗まれたら終わり」を解決する。クライアントは自分の秘密鍵で署名した JWT(DPoP proof)とともにトークンを提示する。リソースサーバはトークン内の cnf.jkt クレームと proof の公開鍵を突き合わせる。

DPoP 普及以前の典型的な攻撃は次の通り。

XSS で SPA の access token を盗む。
攻撃者がその token で直接 API サーバを呼ぶ。
サーバは token しか検証していないので通る。

DPoP はステップ3を破壊する。トークンだけでは足りず、対応する秘密鍵も必要となる。WebCrypto の non-extractable キーと組み合わせれば、SPA からキー自体を抜き取ること自体が困難になる。

2026年5月時点で DPoP を標準サポートする IdP は Keycloak 25、Zitadel、Ory Hydra。Auth0 は enterprise プランで beta、Okta は一部ワークフローのみ、Authentik は2025年12月リリースで安定した。

FAPI 2.0 — 金融 API の新しい床面

FAPI(Financial-grade API)1.0 Advanced は2018年から UK Open Banking で運用されてきた。FAPI 2.0 はその経験を整理して単純化したプロファイルだ。

主な相違点は次の通り。

FAPI 1.0 のレスポンス署名要件(JARM ほか)は単純化された。
mTLS か DPoP か、いずれかで sender-constrained なトークンだけを認める。
PAR(Pushed Authorization Request、RFC 9126)が必須。認可要求はバックチャネルで先にプッシュし、フロントエンドには短い request_uri だけを渡す。
RAR(Rich Authorization Requests、RFC 9396)が標準化され、「1000万ウォン送金を承認」のようなトランザクション単位の認可を表現できる。

韓国マイデータ、日本の電子政府 API、EU PSD3 のいずれも FAPI 2.0 をベースラインに据えつつある。Keycloak は FAPI 2.0 適合性テストを2025年に通過。Authelia は未準拠。Auth0 はアドオン経由で対応する。

Keycloak 25 — Quarkus 移行後の現在地

Keycloak は v18 で WildFly から Quarkus に切り替え、v25 でその決定が安定した。コールドスタートは1秒未満。メモリフットプリントはおよそ半分。コンテナイメージが軽いので Kubernetes 上で HPA も素直に動く。

v25 の主な変更点:

Account Console v2 が React で書き直され、パスキー登録の UX が改善された。
Admin UI も同様に React で書き直し、REST API は安定。
Organizations 機能が GA に。真のマルチテナンシではないが、単一 realm 内で組織単位にユーザを束ねられる。
WebAuthn パスワードレス登録が既定の認証フローに統合された。

# Keycloak 25 の Kubernetes デプロイ(Helm values 抜粋)
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

Keycloak の苦手分野もはっきりしている。本格的なマルチテナント SaaS で、realm を分離して運用するとインスタンスが膨らむ。1インスタンスで数百 realm を運用するとコールドスタートが再び遅くなる。この瞬間に Zitadel の検討が始まる。

Authentik — Outpost が作るもう一つの IdP

Authentik は「プロキシ認証」のユースケースから出発してフル IdP に育ったプロジェクトだ。中核概念は Outpost。IdP コアから分離された別プロセスで、各 Outpost は特定プロトコル(LDAP、RADIUS、Proxy)を担当する。

Outpost モデルの利点:

LDAP サーバが落ちても OIDC フローは影響を受けない。
Outpost は Kubernetes オペレータで自動デプロイされる。
セキュリティ境界が明確。Outpost は IdP DB に直接アクセスせず、API のみを呼ぶ。

Authentik の Flow という概念も興味深い。認証/登録/パスワードリセットをすべて同じ「Flow」抽象で表現する。Stage(MFA、password、prompt、captcha など)を組み合わせて任意の認証手続きを構築する。

# Authentik Flow 例: パスキー優先、TOTP フォールバック
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 の弱点はコミュニティ規模とエンタープライズサポートのオプションだ。BeryJu 社が商用ライセンスを売っているが、Okta 並みの SLA は期待しづらい。

Zitadel — マルチテナンシを正面突破した設計

Zitadel はスイス発の IdP で、初めからマルチテナント SaaS のために設計された。他の IdP と最も違うのは、イベントソーシング + CQRS をコアアーキテクチャに据えた点だ。

すべての状態変化はイベントとして保存される。ユーザ作成、パスワード変更、権限付与、トークン発行 — すべて append-only なイベントログに記録される。現在状態は projection(materialized view)として構築する。設計上の帰結:

全変更履歴が恒久保存され、監査要件を満たしやすい。
Read モデルを多様に作れる。PostgreSQL projection を ClickHouse に移すなど。
ユーザを「巻き戻す」ことができる。誤った権限変更をイベント単位で追跡して補正する。

Zitadel のマルチテナンシは Organization 単位だ。1インスタンスで数千 Organization を運用でき、各 Organization は独自の IdP 設定、独自ドメイン、独自ブランディングを持つ。Keycloak realm を1000本動かすのと、Zitadel Organization を1000個動かすのは運用コストで桁が違う。

弱点は運用学習曲線。CockroachDB 互換の PostgreSQL が必要で、イベントログが急速に膨らむため保持ポリシーを明示する必要がある。

Ory Hydra — ヘッドレスな OAuth 2.1 サーバ

Ory Hydra は OIDC / OAuth 2.1 仕様適合性のみを目標にする。UI はない。ユーザ DB もない。ログインページもない。すべて「consent app」という別アプリケーションが担当する。

Hydra の認証フローは次の通り。

クライアントが /oauth2/auth にユーザを送る。
Hydra はユーザを自分自身ではなく、別途ホストされている login app にリダイレクトする。
Login app がユーザ認証を行い、Hydra に「このサブジェクトを受け入れろ」と通知する。
Hydra が consent ステップへリダイレクト。
同じパターンが繰り返された後、Hydra がトークンを発行する。

// Ory Hydra login app の例(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,
  })

  // 自前の認証ロジック(パスキー、パスワード、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 が合うのは、会社がすでにユーザ DB とログイン UI を持っていて、OIDC / OAuth だけを追加したい場合だ。Hydra が合わないのは「とにかく IdP が欲しい」平均的なケース。そのときは Keycloak や Zitadel のほうがずっと早い。

Auth0 のポジション — Okta 買収から4年

Okta は2021年に Auth0 を買収した。4年が経った2026年時点で、2製品ははっきり別の市場を狙う。

Auth0 = 開発者フレンドリー、B2C、迅速統合、Rules → Actions 移行完了。
Okta Workforce = エンタープライズ SSO、Universal Directory、Lifecycle Management。
Okta Customer Identity Cloud = Auth0 のリブランディング + エンタープライズ営業。

Auth0 の価格は2024-2025年に大幅に上がった。無料枠は縮小し、MAU 課金は急峻になった。100万 MAU 基準で月額が2021年比でおよそ2.5倍に上がった公開事例が複数ある。それがセルフホスト IdP への移行が再び活発になっている根本理由だ。

Auth0 の強みは依然として DX。SDK 品質、ドキュメント、サポート — この領域はセルフホストの選択肢が追いついていない。素早い PoC や初期段階のスタートアップには今でも合理的だ。

WorkOS — B2B のみ正面から狙ったプロダクト

WorkOS は「エンタープライズ顧客が SSO を求めたとき、素早く対応できるようにする」という命題で作られた SaaS だ。中核価値は次の通り。

SAML、OIDC、SCIM を統一 API で提供。
「Directory Sync」— Okta、Azure AD、Google Workspace、BambooHR など30以上のディレクトリを同一モデルで吸収。
B2C はやらない。コンシューマ向けの登録、パスワードリセット、IDリカバリは別ソリューションに任せる。

WorkOS が合うシナリオ:

自社製品はすでに自前認証を持っている。
これからエンタープライズ顧客が「Okta SSO 必要です」と言ってくる。
SAML メタデータ交換を IdP ごとに別実装するのは避けたい。

このシナリオで WorkOS は1エンドポイントに統合する。Auth0 にも似た機能があるが、WorkOS はそれしかやらないため価格と単純性で勝つ。

Okta の現在 — インシデント後の信頼回復

Okta は2022年に Lapsus$ 事案、2023年に HAR ファイル流出を経験した。2026年現在はセキュリティガバナンスを大幅に立て直し、全顧客を OIE(Okta Identity Engine)に移行させた。それでも一部のエンタープライズは「single vendor risk」を理由に補助 IdP を運用する。

Okta の強みは変わらない。

7000以上のプリビルド統合(Okta Integration Network)。
Lifecycle Management — HR システムの変更がそのまま権限変更につながる。
Adaptive MFA — デバイス、位置、行動に基づくリスク評価。

弱点は価格、ロックイン、そして Okta が落ちると会社全体が落ちる依存度だ。後者への備えとして「Okta ダウン時の迂回ログイン経路」をランブックに書く会社が増えた。

FedCM — ブラウザがフェデレーションを仲介する

FedCM は ID フェデレーションを third-party cookie なしで成立させるブラウザ API だ。従来の「Google でログイン」ボタンは third-party iframe とリダイレクトに依存していた。third-party cookie が消える世界では、このフローは壊れる。

FedCM の動作:

RP(Relying Party)が navigator.credentials.get({ identity: { providers: [...] } }) を呼ぶ。
ブラウザが IdP のマニフェストを取得する。
ブラウザがシステム UI で「このサイトを X.com のアカウントでサインインさせる」ダイアログを表示する。
ユーザ同意のもと、ブラウザが IdP から ID token を取得し RP に渡す。

# FedCM IdP マニフェストの例
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 は Chrome 132 で安定。Edge 132 でも同じインタフェースを有効化。Safari は2026年5月時点で「検討中」段階。Keycloak 25 は FedCM IdP エンドポイントを実験的に提供。Zitadel は正式サポートを発表中。Auth0 と Okta は RP 側 SDK を先行提供する。

パスキーと WebAuthn — もはや「新技術」ではない

2026年のパスキー採用率はティッピングポイントを越えた。Microsoft アカウントのおよそ30%がパスキーを使い、Apple iCloud Keychain はほぼ全 iOS ユーザでパスキー同期を有効化した。Google アカウントも同様の比率だ。

IdP 視点でパスキー実装時の注意点:

Resident key(discoverable credential)と non-resident key の違いを理解する。パスキーは resident key だ。
Cross-device authentication(CDA、hybrid transport)を支えるとデスクトップでもモバイルのパスキーが使える。
Attestation 方針を決める。エンタープライズは通常 packed attestation を要求する。
パスキー喪失時のアカウントリカバリ動線が貧弱だとユーザは詰む。

Keycloak 25 はパスキー登録を既定の認証フローに統合。Authentik は WebAuthn stage が GA。Zitadel は最初から WebAuthn first-class。Ory は Hydra 自体には無く Kratos が担当。Auth0 は「Universal Login」にパスキーオプションを提供。

SCIM と JIT プロビジョニング

エンタープライズ顧客はほぼ常に SCIM(System for Cross-domain Identity Management)を要求する。HR システムでユーザが追加されたら自動で自社サービスのユーザが生まれ、HR で無効化されれば即座にロックされる。

SCIM 2.0 標準エンドポイント:

/scim/v2/Users — ユーザ CRUD
/scim/v2/Groups — グループ CRUD
/scim/v2/Bulk — 一括変更
/scim/v2/ServiceProviderConfig — 自社サービスがサポートする SCIM オプションの広告

SCIM の落とし穴は仕様の曖昧さだ。userName と emails[].value のマッピング、group membership の同期方向(IdP push vs SP pull)、soft delete と hard delete — どの部分でも IdP の実装が異なる。WorkOS はこの差を吸収して単一 API で公開する。それが WorkOS の価値だ。

JIT プロビジョニングは SCIM の軽量代替だ。ユーザが初回ログインしたとき、IdP が送ってきた SAML/OIDC アサーションのクレームに基づいてユーザレコードを生成する。素早いが即時の無効化(deprovisioning)はできないという短所がある。

Identity broker パターン — 韓国 PASS と日本 JPKI の統合

韓国のマイデータ、本人認証サービスは PASS、Kakao、Naver、Toss といった本人確認機関(IdP ではなく本人確認機関であることに注意)を経由する。日本はマイナンバーカードに基づく JPKI(公的個人認証サービス)が政府認証の標準だ。

自社サービスがこうした認証を直接統合すると、毎回違うプロトコル、違うレスポンス形式、違う更新周期を扱う必要が出る。Identity broker パターンは IdP を中間に置き、外部 IdP / 本人確認機関の統合は IdP に責任を持たせる。

Keycloak の Identity Provider 機能、Zitadel の External IdP、Auth0 の Custom Connection がこのパターンを支援する。韓国の文脈では次のようにマッピングする。

PASS API → IdP の custom OIDC provider にアダプト
Kakao sync → IdP の OAuth 2.0 provider に登録
Naver → IdP の OAuth 2.0 provider
本人確認(KISA 認証) → IdP の custom SAML または custom provider

JPKI はさらに複雑だ。PIN 入力、カードリーダ連携、JPKI client app の呼び出しが必要となる。IdP は通常 JPKI client とのインタフェースのみを標準化し、実際のカード通信はユーザのデバイス上で行われる。

B2B vs B2C — 同じ IdP で両方できるか

B2C ではユーザが自分のメールで登録し、自分のパスキーでログインする。会社が管理するわけではない。

B2B ではユーザが会社のメールで登録する。会社が SSO を運営し、ユーザは会社の IdP 経由で自社サービスに入ってくる。ユーザ権限は会社が管理する。

同じ IdP で両方を捌けるか? できるが推奨しない。ユーザモデル、認証フロー、認可モデルが違いすぎる。現実的なパターンは通常こうなる。

B2C は Auth0、Cognito、自前実装で始める。
最初のエンタープライズ顧客が SSO を要求。WorkOS を追加して SAML を吸収。
ユーザが増えるにつれてセルフホスト IdP(Keycloak / Zitadel)へ移行。
その時点で B2B と B2C のテナントを分ける。

この進化経路を最初から予期して設計しておけば移行コストは小さい。1つの IdP に全部詰め込んでから分離するとコストが大きい。

MFA の進化 — SMS は死に、パスキーが標準になった

NIST SP 800-63-4 は SMS OTP を AAL2 の推奨認証器から外した。SS7 攻撃、SIM swap 攻撃により SMS はもう安全ではない。それでも2026年時点で多くのサービスが SMS OTP を使う。理由は1つ、「ユーザは追加アプリを入れたがらない」。

代替:

パスキー — 最も安全。デバイス喪失時のリカバリが課題。
TOTP(Google Authenticator、Aegis) — 依然合理的な MFA。
Push notification(Authy、Duo) — phishing-resistant モードと併用すれば安全。
Hardware key(YubiKey) — エンタープライズ標準、紛失時のバックアップキーが必要。

IdP で MFA を強制する方針は risk-based であるべきだ。全ログインで MFA を要求するとユーザは抜け道(Cookie 永続化など)を作る。「新しいデバイスで、新しい IP で、機微な操作の直前」に MFA を要求するのが現実的だ。

セッション管理とトークン失効

OIDC の難所の1つは「ユーザがログアウトしたら全 RP で同時にログアウト」だ。front-channel logout と back-channel logout の仕様はあるが、実装が不完全な IdP が多い。

トークン失効(revocation)は OAuth 2.1 でさらに重要になる。シナリオ:

ユーザのスマホが盗まれた。
社内 IT が IdP でそのユーザの全セッションを終了する。
すでに発行済みの access token は期限切れまで(通常5-60分)API アクセスが通る。

この5-60分のギャップを縮めるには:

Access token の寿命を短く(5分以下)する。トラフィックは増えるが安全。
すべての API 呼び出しで token introspection(RFC 7662)を行う。高価だが即時失効。
あるいは失効リストをキャッシュする。Sliding cache で新しい失効情報を素早く反映する。

Keycloak、Zitadel、Auth0 はすべて introspection エンドポイントを提供する。Ory Hydra はもっと軽く、自己完結型検証と introspection を混在させる。

セルフホスト IdP の本当のコスト

「オープンソースの IdP はタダ」というのはライセンスしか見ていない。実際のコストは次のように積み上がる。

HA 運用: PostgreSQL primary/replica、IdP インスタンス3台以上、ロードバランサ、証明書ローテーション。
バックアップ/リストアの訓練。
セキュリティパッチ追跡。CVE 発生時の24時間以内パッチ適用責任。
24/7 オンコール。Okta が落ちることと自社 IdP が落ちることはユーザから見れば同じ。
コンプライアンス監査。SOC 2 type II を取得する会社では IdP も監査対象。

100万 MAU 基準のおおまかな試算:

Auth0 / Okta CIC: 月額 $20,000-30,000。
セルフホスト Keycloak または Zitadel: インフラ月額 $1,000-3,000 + フルタイムエンジニア 0.5-1名。

会社規模と自社運用能力により損益分岐点は異なる。ユーザ30万未満なら SaaS のほうが大抵安い。200万以上ならセルフホストのほうが大抵安い。

攻撃面 — トークン盗難、refresh rotation、OAuth phishing

2025-2026年に報告された OAuth 関連の攻撃トレンド:

OAuth phishing — 偽のクライアント ID で本物の IdP の consent 画面を経由させ、ユーザに権限付与させる攻撃。Google と Microsoft が application verification 強化で対応中。
Refresh token replay — refresh rotation がなければ一度盗んだ refresh token で無限に再発行可能。RFC 6749 4.1.4 では rotation は SHOULD だが、2026年では MUST に近い位置付け。
悪意あるブラウザ拡張によるトークン盗難 — 拡張機能が SPA メモリからトークンを読み出す。DPoP + non-extractable WebCrypto キーで緩和できる。
Open redirector chain — RP の杜撰な redirect_uri 検証でトークンが外部ドメインに漏れる攻撃。OAuth 2.1 の exact match 要求がこれを減らす。

IdP を運用するとは、これらの攻撃を IdP レベルで遮断し、RP 開発者には安全な SDK だけを露出することを意味する。

エンタープライズ SSO 調達の現実 — SAML は死なない

スタートアップのエンジニアは「なぜまだ SAML?」と問う。答え: エンタープライズが SAML を求めるからだ。

エンタープライズ IT 部門の視点では:

SAML には20年の運用経験がある。デバッグツール、既知の落とし穴、標準的なメタデータ交換手順がすべて確立されている。
OIDC は比較的新しく、IdP ごとに実装が異なる。
セキュリティレビュー委員会は SAML を「安全なデフォルト」とみなす。

だから自社サービスがエンタープライズを受け入れるためには OIDC と SAML の両方をサポートしなければならない。WorkOS、Auth0、Okta CIC、Keycloak、Zitadel はすべて両方をサポートするが、実装品質とメタデータ交換の自動化レベルは異なる。

調達プロセスでよく出る要求:

SAML metadata URL の提供
AuthnRequest 署名オプション
SLO(Single Logout)サポート
IdP-initiated SSO サポート(セキュリティリスクはあるがエンタープライズはしばしば要求する)
グループマッピング(Active Directory group → サービス role)

韓国環境の追加コンテキスト — PASS、KISA、本人認証

韓国で SaaS を運営するときに直面する認証要件:

本人認証 — 住民登録番号に基づく本人確認。KISA 認証を受けた本人確認機関(NICE、KCB、SCI)を経由する必要がある。
PASS — 通信3社が運営する統合認証アプリ。本人認証の主要チャネル。
マイデータ — 金融データのポータビリティ。FAPI 1.0 Advanced ベース。
電子署名法改正(2020)以降、公認認証書は廃止され、各種民間認証が認められた。

自社 IdP に本人認証を統合する際の注意:

本人確認結果は IdP のユーザプロファイルに保存。ただし住民登録番号はハッシュ化して保管(法的要件)。
CI(連係情報)と DI(重複確認情報)は意味が違う。CI はサービス間の同一人物識別、DI は1サービス内の重複登録防止。
本人確認結果の有効期間(通常6か月から1年)を方針として管理する。

日本環境の追加コンテキスト — JPKI、マイナンバー、OpenID Connect for Identity Assurance

日本はマイナンバーカードに基づく JPKI が政府認証の標準だ。JPKI はカード内に2つの証明書を持つ。署名用証明書と利用者証明用証明書。

サービス統合時:

「JPKI 利用者証明用電子証明書」で OIDC ログインが可能(PIN 4桁)。
「JPKI 署名用電子証明書」は本格的な電子署名に使う(PIN 6-16文字)。
マイナンバー(個人番号)自体は絶対に IdP に保存しない(マイナンバー法違反)。

OpenID Connect for Identity Assurance(OIDC4IDA)は日本政府が標準化に参加している仕様で、IdP がユーザの本人確認レベル(Level of Assurance)を RP に伝えるためのものだ。JPKI 統合 IdP は OIDC4IDA の verified_claims を通じて「このユーザはマイナンバーカードで本人確認を終えた」と信頼性ある形で伝える。

# OIDC4IDA レスポンスの例(抜粋)
{
  "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"
    }
  }
}

マイグレーションシナリオ — Auth0 から Keycloak へ

実際によく見るシナリオ: Auth0 で始めたが価格上昇後にセルフホストへ移行する。

マイグレーションチェックリスト:

ユーザデータの export — Auth0 Management API でユーザとメタデータを export。パスワードハッシュが bcrypt ならそのまま import 可能。それ以外なら reset メールを送る。
Application / Client マッピング — Auth0 Application = Keycloak Client。redirect URI、allowed origins、grant types を1対1で移す。
Rules / Actions のマイグレーション — Auth0 の JavaScript フックは Keycloak の Authenticator SPI または Event Listener SPI として再実装する必要がある。自動マイグレーションツールはない。
Connection(ソーシャル IdP) — Google、GitHub、Apple などの OAuth client ID / secret を Keycloak Identity Provider として再登録。
ダウンタイムなしの cut-over — DNS 切り替え前に両方のシステムが同一のユーザ集合を持つよう同期する。通常は incremental migration か dual-write 期間を設ける。

マイグレーション期間中に最も頻繁に壊れるもの: パスワードハッシュアルゴリズムの不一致、そして user_id 形式の変更による外部システム参照の破壊。

結論 — 2026年の意思決定ツリー

長い記事だが、意思決定はシンプルにできる。

ユーザ30万未満で運用人員が不足 → Auth0 または Okta CIC。
B2B 専業でエンタープライズ SSO / SCIM が中核 → WorkOS。
セルフホスト可能、単一テナントで十分 → Keycloak 25。
セルフホストが必要、真のマルチテナント SaaS → Zitadel。
自前ユーザ DB があり OIDC だけ追加 → Ory Hydra。
プロキシ認証や軽量ユースケース → Authentik。
巨大エンタープライズで7000統合が必要 → Okta Workforce。

選んだ後は必ず以下を検証する。

OAuth 2.1 適合性(PKCE 強制、implicit 拒否、refresh rotation)。
DPoP または mTLS のサポート。
FAPI 2.0 が必要な業界なら適合性認証書の確認。
FedCM IdP エンドポイントのロードマップ。
パスキー登録 / 使用 / リカバリフローの完成度。
SCIM 2.0 の双方向サポート。
韓国 / 日本の地域統合(PASS、JPKI)の可否。

2026年の SSO はもはや「ログインボックス」ではない。ユーザ ID の全ライフサイクル、デバイスバインディング、規制適合、ブラウザ仲介フェデレーションを同時に扱うインフラ部品だ。よく選んだ IdP は5年もつ。誤って選んだ IdP は1年分のエンジニアリングをマイグレーションで燃やす。