LabHub

ブログ

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-05-16 · 33 分で読めます · #keycloak#authentik#zitadel#ory-hydra#auth0#workos#okta#sso#oidc#saml#oauth2#fapi#fedcm#webauthn

한국어English日本語

コールドオープン — 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 は、同じ市場で戦っていない。語彙は似ているが、実際のポジションは違う。

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

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

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

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

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 普及以前の典型的な攻撃は次の通り。

  1. XSS で SPA の access token を盗む。
  2. 攻撃者がその token で直接 API サーバを呼ぶ。
  3. サーバは 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 はその経験を整理して単純化したプロファイルだ。

主な相違点は次の通り。

韓国マイデータ、日本の電子政府 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 の主な変更点:

# 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 モデルの利点:

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)として構築する。設計上の帰結:

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 の認証フローは次の通り。

  1. クライアントが /oauth2/auth にユーザを送る。
  2. Hydra はユーザを自分自身ではなく、別途ホストされている login app にリダイレクトする。
  3. Login app がユーザ認証を行い、Hydra に「このサブジェクトを受け入れろ」と通知する。
  4. Hydra が consent ステップへリダイレクト。
  5. 同じパターンが繰り返された後、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 の価格は2024-2025年に大幅に上がった。無料枠は縮小し、MAU 課金は急峻になった。100万 MAU 基準で月額が2021年比でおよそ2.5倍に上がった公開事例が複数ある。それがセルフホスト IdP への移行が再び活発になっている根本理由だ。

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

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

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

WorkOS が合うシナリオ:

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

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

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

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

Okta の強みは変わらない。

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

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

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

FedCM の動作:

  1. RP(Relying Party)が navigator.credentials.get({ identity: { providers: [...] } }) を呼ぶ。
  2. ブラウザが IdP のマニフェストを取得する。
  3. ブラウザがシステム UI で「このサイトを X.com のアカウントでサインインさせる」ダイアログを表示する。
  4. ユーザ同意のもと、ブラウザが 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 視点でパスキー実装時の注意点:

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 の落とし穴は仕様の曖昧さだ。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 がこのパターンを支援する。韓国の文脈では次のようにマッピングする。

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

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

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

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

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

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

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

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

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

代替:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サービス統合時:

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 で始めたが価格上昇後にセルフホストへ移行する。

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

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

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

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

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

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

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

References

コメント

まだコメントはありません。

ログインするとコメントできます