💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 2026年、SSOはもう「あれば良い」ではない

2010年代、SSOは「大企業の贅沢品」だった。2020年代前半は「必要だが高い」というグレーゾーン。そして2026年、SSOは**あらゆる組織の標準インフラ**になった。

理由は単純だ。

- 一人の従業員が平均80以上のSaaSを使い、入社・退職を手作業で追うのは不可能。

- **NIS2**(EU)、**DORA**(EU金融)、**PCI DSS 4.0.1**、**HIPAA Security Rule 2024**、**SOC 2 Type II** が一斉に**集中型IAM**、**MFA**、**セッション可視性**を明示的に要求するようになった。

- **Passkeys**(WebAuthn / FIDO2)が Apple、Google、Microsoft の三者すべてで同期可能になり、「パスワードレス認証」が一般ユーザーにとっても現実になった。

- **Auth0 ロックイン**、**Cognito 機能廃止**、**ForgeRock → Ping 統合**といった出来事がマネージドIdPへの信頼を揺るがし、**Keycloak・Authentik・Ory** のようなOSS代替が再び浮上した。

本稿はその地形を一度に整理する。標準から出発し、OSS IdP、マネージドSaaS、ライブラリ勢、認可分離の潮流、韓国と日本の現実まで。

> 一行要約: **「誰が認証し、誰が認可し、その判断の証跡はどこに残り、人が離れたときどう片付くのか。」** この四つの問いに答えられないなら、どんなIdPを導入しても意味はない。

第1章 · SSOが解こうとしている本当の問題 — 人・アカウント・セッション・監査

SSOを「一度ログインすれば済むこと」と理解すると本質を見落とす。実際の問題は四層構造だ。

| レイヤ | 問題 | SSOが答える方法 |

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

| アイデンティティ | 一人の人間が会社に何人として存在するか | 単一のユーザーオブジェクト、単一ID |

| アカウント | 50個のSaaSに50個のパスワードが生きているか | フェデレーテッドログイン、JITプロビジョニング |

| セッション | ノートPC盗難時に50ヶ所一斉にログアウトできるか | 中央セッション、Single Logout(SLO) |

| 監査 | 誰がいつどこから何にアクセスしたか | 中央イベントログ、SIEM連携 |

ここに**プロビジョニング/デプロビジョニング**(SCIM)、**認可決定**(Authorization)、**MFA強制**、**異常行動検知**(Adaptive Auth)が積み重なる。

良いSSOは単なる「ログイン統合」ではなく、**「人のライフサイクルをインフラとして扱う仕組み」** である。

第2章 · コア標準 — OAuth 2.1、OIDC、SAML、SCIM、WebAuthn

2026年に押さえておくべき五つの標準。

| 標準 | 何をするか | どこで使うか |

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

| OAuth 2.1 | APIへの委任認可 | API呼び出し、モバイルアプリ、SPA |

| OpenID Connect (OIDC) | OAuthの上に乗る「ログイン」層 | Web/モバイルのユーザー認証 |

| SAML 2.0 | XMLベースのエンタープライズSSO | 既存SaaS、Workday、Salesforce |

| SCIM 2.0 | ユーザー/グループのプロビジョニング | Okta → Slack、Entra → Zoom |

| WebAuthn / FIDO2 | パスワードレスの強い認証 | Passkeys、YubiKey、Touch ID |

**OAuth 2.1** はIETFがOAuth 2.0のベストプラクティスを一つの必須プロファイルに統合したものだ。次の四つが **MUST** に格上げされた。

1. **PKCE**(Proof Key for Code Exchange)を全クライアントに必須化。

2. **Implicit flow** を削除。SPAも Authorization Code + PKCE を使う。

3. **Resource Owner Password Credentials** グラントの削除。

4. **Redirect URI の完全一致** — ワイルドカード禁止。

**OIDC** は OAuth の上に ID Token(署名済みJWT)を載せ、「このトークンを持っている者は本当にユーザーXである」と言えるようにする。`iss`、`sub`、`aud`、`exp`、`iat`、`nonce` が標準クレーム。

**SAML 2.0** は XML/SOAP 時代の遺物だが、エンタープライズでは依然として90%以上を占める。OIDCに乗り換えられないSaaSが多すぎる。

**SCIM 2.0** はIdPがダウンストリームSaaSのユーザーディレクトリを自動で埋める標準だ。「Oktaで従業員が退社処理されればSlackで自動的に無効化」がSCIMの日常。

**WebAuthn / FIDO2** は公開鍵ベース認証で、パスワード自体を廃止する。2024-2026にかけて Apple iCloud Keychain、Google Password Manager、1Password、Bitwarden がすべて **Passkey 同期**に対応し、事実上の一般ユーザー標準になった。

第3章 · OAuth 2.1 — PKCE、PAR、JAR、DPoP

OAuth 2.1 の上にセキュリティ強化のための四つの拡張が標準化された。

**PKCE**(RFC 7636)— Authorization Code の傍受を防ぐ。クライアントが乱数の `code_verifier` を生成し、そのSHA-256ハッシュ(`code_challenge`)を認可リクエストに乗せる。トークン交換時に再度 `code_verifier` を提示して同じクライアントであることを証明する。

**PAR**(Pushed Authorization Requests、RFC 9126)— 認可リクエストのパラメータをブラウザURLに露出させず、バックチャネルでIdPに事前プッシュする。ブラウザは返ってきた `request_uri` だけを持ち回る。

**JAR**(JWT-Secured Authorization Request、RFC 9101)— 認可リクエスト自体を署名済みJWTとして送る。パラメータ改ざんを防ぐ。

**DPoP**(Demonstrating Proof-of-Possession、RFC 9449)— Bearer トークンの弱点(持っていれば使える)を補う。クライアントが毎リクエストで自分の鍵で署名した `DPoP` ヘッダを付け、「このトークンは私の鍵に縛られている」という証拠を送る。

2026年のIETF OAuth 2.0 Security BCP ドラフトは事実上この四つを**推奨または要求**している。

疑似フロー — Authorization Code + PKCE + PAR + DPoP

1) クライアントが PAR で認可パラメータをプッシュ

POST /as/par

client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256

2) IdP が request_uri を返す

3) ブラウザは request_uri だけを持って IdP に移動

GET /as/authorize?client_id=...&request_uri=urn:ietf:params:oauth:request_uri:abc

4) ログイン後、IdP が redirect_uri に code を返す

5) クライアントが token endpoint で code + code_verifier を交換

6) 以後のリソース要求すべてに DPoP ヘッダを付与

第4章 · OIDC — ID Token、Userinfo、Discovery、Logout

OIDCがOAuthと違う点は三つ。

1. **ID Token** — ユーザー情報を含むJWTがアクセストークンと共に発行される。

2. **/userinfo エンドポイント** — アクセストークンでユーザープロフィールを取得する経路。

3. **Discovery ドキュメント** — `/.well-known/openid-configuration` であらゆるエンドポイントと鍵の位置を発見できる。

標準的なID Tokenのペイロードはこんな形だ。

{

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

}

検証時に必ず確認すべきクレーム:

- `iss` — 信頼するIdPか

- `aud` — 自分のクライアントIDか

- `exp` と `iat` — 時間枠が有効か

- `nonce` — 認可リクエストで送った値と一致するか

- 署名 — JWKS(`jwks_uri`)から鍵を取得して検証したか

**Single Logout** はOIDCが最後まで綺麗に解けなかった部分だ。バックチャネルとフロントチャネルどちらにも穴がある。2026年の運用パターンは「**短いアクセストークン + リフレッシュトークン回転 + IdPセッション無効化時の即時失効**」へとシフトしている。

第5章 · SAML 2.0 — 死なないXML

エンタープライズでSAMLが消えない理由は二つ。**第一に**、既設SaaSのかなりの部分がSAMLしか喋れない。**第二に**、IT・監査部門がSAMLアサーションの形に慣れている。

SAML SSOのフローはOIDCより手数が多い。

1. ユーザーがSP(Service Provider、例えば Salesforce)にアクセス。

2. SPがSAMLRequestを作りIdP(例えば Okta)にリダイレクト。

3. IdPがログイン後、署名付きSAMLResponse(XML)をSPのACS URLにPOST。

4. SPがアサーションを検証してセッションを作る。

alice@example.com

SAMLの弱点は周知だ。XML署名ラッピング回避、アサーションリプレイ、メタデータ改ざんなど攻撃面が広い。2026年の標準パターンは「新規連携はOIDC、既存SaaSはSAML維持」という**二重運用**である。

第6章 · SCIM 2.0 — プロビジョニング標準

**SCIM**(System for Cross-domain Identity Management、RFC 7643/7644)はIdPがSaaSのユーザーディレクトリにユーザー/グループをプッシュするREST API標準だ。

主要エンドポイント:

| エンドポイント | 用途 |

| --- | --- |

| /Users | ユーザーCRUD |

| /Groups | グループCRUD |

| /Schemas | スキーマメタデータ |

| /ServiceProviderConfig | サポート機能 |

| /Bulk | 一括更新 |

{

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

}

人事システムで従業員が退社処理されると、IdPはSCIM PUTで `active=false` を連携先SaaSに反映する。この経路が壊れているSaaSはセキュリティ債務になる。

2026年現在、SCIMをサポートしないSaaSはエンタープライズ市場でほとんど生き残れない。Slack、Notion、Figma、Linear、Datadog、GitHub Enterprise はすべて対応している。

第7章 · WebAuthn / FIDO2 / Passkeys — パスワードの終焉

**WebAuthn**(W3C)と **FIDO2 CTAP2**(FIDO Alliance)は同じ問題を解く。ユーザーのデバイスに秘密鍵を保存し、認証時にチャレンジに署名する。パスワードはそもそも存在しない。

中核フロー:

1. **登録(Registration)** — ユーザーがデバイス上で鍵ペアを生成し、公開鍵だけをサーバーに登録。

2. **認証(Authentication)** — サーバーがチャレンジを送り、デバイスが秘密鍵で署名、サーバーは公開鍵で検証。

**Passkeys** はWebAuthn認証器が同期可能な形に進化したものだ。Apple iCloud Keychain、Google Password Manager、1Password、Bitwarden すべてがデバイス間同期に対応している。

// WebAuthn 登録 - 簡略化した擬似コード

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"

}

})

// credential.response.attestationObject をサーバーに送信 → 検証 → 公開鍵保存

2026年現在、Google、Microsoft、Apple、GitHub、Shopify、PayPal、Amazon すべてが Passkey ログインに対応している。日本では LINE、メルカリ、KDDIなどが一部対応段階。

第8章 · Keycloak 26 / 26.1 — OSS IdPの事実上の標準

**Keycloak** は2014年にRed Hatが始めたOSS IdPだ。2024年に26.0がLTSとして公開された後、26.1まで漸進的改善が続いた。2026年時点で、セルフホスティング型IdPの事実上の標準である。

26ラインの変化は大きい。

- **Quarkus ベースの書き直し** — 19.x までのWildFly基盤が完全に整理され、Quarkus 単一ディストリビューションに統一。

- **Account Console v3** — ユーザーが自分のアカウントを管理する新UI(React + i18n)。

- **Organizations** — 単一Realmの中に複数組織を持つマルチテナンシーモデル(26.0でGA)。

- **Fine-Grained Admin Permissions v2** — 管理者権限をRealm・リソース単位で細かく分けるモデルの再設計。

- **mTLS Client Authentication** — クライアントがmTLSで認証。

- **DPoP サポート** — トークンのsender-constraining。

- **OAuth 2.0 Step-Up Authentication Challenge** — 機微操作時に追加認証を要求。

**Red Hat build of Keycloak**(RHBK)は同じKeycloakにRed Hatのライフサイクル・CVEパッチ保証を被せた商用版だ。ライセンスは依然 Apache 2.0。

第9章 · Keycloakの中核概念 — Realm、Client、IdPブローカリング、User Federation

Keycloakを最初に触るとき混乱するのは語彙だ。

| 語 | 意味 |

| --- | --- |

| Realm | 隔離されたユーザー/クライアント空間。環境やテナント単位 |

| Client | 認証を委任するアプリ(Web、モバイル、サービスアカウント) |

| Identity Provider | Keycloakが委任先にする外部IdP(Google、GitHub、SAML IdPなど) |

| User Federation | LDAP/ADなど既存ディレクトリをユーザーソースとして取り込む |

| Roles | RealmまたはClient範囲の権限 |

| Groups | ユーザーの集合。ロールや属性を継承可能 |

| Authentication Flow | ログインのシナリオ(ブラウザ、ダイレクト、リセットなど) |

| Theme | HTML/CSS/JSのカスタマイズ単位(login、account、admin、email) |

**Identity Brokering** は外部Google/GitHub/MicrosoftログインをKeycloakが受け取り、内部ユーザーにマップする機能。ユーザーは外部IdPで認証するが、自分のアプリは常にKeycloakだけを見る。

**User Federation** は逆だ。既存のLDAP/ADをユーザーソースとして使い、認証はKeycloakが担う。データ移行なしで段階的に移行できる。

**SPI**(Service Provider Interface)はほぼあらゆる領域に拡張ポイントを提供する。ユーザーストレージ、認証フロー、イベントリスナー、トークンマッパー、メールテンプレートなど。Javaで書いたjarを `providers/` に置きビルドステップを走らせれば登録される。

第10章 · Keycloakの運用 — Docker Compose、Helm、PostgreSQL、HA

正直な単一ノード運用の姿はこうだ。

シンプル運用 - 単一ノード - 外部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:

本番に近づくほど気にすべきこと。

- **HA** — Infinispan分散キャッシュ + Postgresリードレプリカ。Kubernetes Operatorが標準。

- **TLS終端** — nginx/HAProxy/Traefikで終端し、Keycloakにはproxyヘッダを信頼させる。

- **バックアップ** — 状態はすべてPostgresにある。Realmのexport/importは補助。

- **モニタリング** — Prometheusメトリクス(`/metrics`)、イベントリスナーで Kafka / SIEM に流す。

- **テーマ** — login/account/admin の三種に自社デザインを反映。

最も多い運用ミス: 管理者パスワードを環境変数のまま永続放置、Realm exportに秘密まで含めてバックアップ、Postgresバックアップ方針なし、JVMメモリのデフォルト放置。

第11章 · Authentik 2025 — Beryjuが作る現代的代替

**Authentik**(beryju.io)は Python / Django で書かれた比較的新しいOSS IdPだ。2025年ラインで安定化が進み、Keycloakの次の座を固めた。

特徴:

- **Flow ベースの認証** — ログインをノードグラフで構成。ステップ追加、条件分岐、外部呼び出しがすべてGUI操作。

- **現代的UI** — Lit + TypeScript で作られた管理コンソール。Keycloak管理UIの不便さを公然と意識した設計。

- **プロトコル** — OAuth 2.0/OIDC、SAML 2.0、LDAP(サーバー側)、Proxy、RADIUS すべて対応。

- **Outpost** — Proxy・LDAP・RADIUSなどの補助サービスをコンテナで配備。

- **Enterprise** — 2024年以降の有料プラン(GeoIP、Audit、RAC、Wizard)が追加された。

2026年にセルフホスト型IdPをゼロから始めるなら、デフォルトの問いは「Keycloak vs Authentik」になる。巨大なLDAP/AD資産があるならKeycloak。OIDCだけで始めるならAuthentikが多い答え。

第12章 · Authelia 4.39 — リバースプロキシと結合する自己ホスト型2FA

**Authelia**(authelia.com)は Go で書かれた自己ホスト型認証ポータルだ。他のIdPとは結合方式が違う。

中核モデル: **nginx/Traefik/Caddy のようなリバースプロキシでForwardAuthによる認証強制**。AutheliaはIdPというより**保護ゲートウェイ**である。

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;

}

このモデルが効くシナリオは二つ。

1. **OIDC非対応のレガシーアプリ**に統一2FAを強制したい時。

2. **自己ホスト型ホームラボ**で Nextcloud、Jellyfin、Paperless-ngx、ARR系ツールに一括で認証を被せたい時。

AutheliaはOIDC発行も部分的にサポートするが、本業はForwardAuthゲートウェイだ。Keycloak/Authentikの代替ではなく**補完**として位置付けるのが正しい。

第13章 · Casdoor、Ory Stack、Logto — OSSの新勢力

**Casdoor**(casbin.org)は Go で書かれたモジュール型IAMだ。OAuth 2.0/OIDC、SAML、CAS、LDAP、RADIUS すべてに対応し、マルチテナンシーが自然。Casbin(RBAC/ABAC ポリシーエンジン)と同じ組織のため認可が強い。

**Ory Stack** は Go の複数モジュールのまとまりだ。

| コンポーネント | 役割 |

| --- | --- |

| Kratos | サインアップ/ログイン/リカバリ/MFA(Identity) |

| Hydra | OAuth 2.0 / OIDC サーバー |

| Keto | ReBAC(Zanzibar)認可 |

| Oathkeeper | ポリシー駆動リバースプロキシ |

Oryは**ヘッドレス**を標榜する。UIを持たずAPIだけを提供するため、Next.js や Flutter など自前UIに合わせて統合しやすい。

**Logto**(logto.io)は2022年に出た比較的新しいOSS IdP。開発者体験を最優先にSDK、コンソール、ダークモード、M2M、RBAC、Organization をうまく整えている。マネージドCloudオプションもある。

**SuperTokens** と **FusionAuth**(商用と自己ホスト両方)も同じスロットの競合だ。ライセンス、価格、UI品質が選択の決め手になる。

第14章 · Auth0 — マネージドの古典

**Auth0**(2013年創業、2021年 Okta が買収)はマネージドIdPの事実上の原点だ。2026年現在もSaaSスタートアップのデフォルト選択肢として残っている。

長所:

- **Universal Login** — ホストされたログインページ。セキュリティパッチはAuth0責任。

- **Actions / Rules**(Actionsに統合中)— 認証フローのフックに任意JSを差し込み、クレーム追加、外部API呼び出し、MFA強制などを行う。

- **Adaptive MFA / Bot Detection** — リスクスコアに基づくMFA強制。

- **Branding と i18n** — ほぼ全画面がテーマ・言語でカスタマイズ可能。

- **Connections** — Database、Social(Google/GitHub/Apple)、Enterprise(SAML/AD/LDAP)、Passwordless。

最大の弱点は**価格とロックイン**だ。テナント移行は可能だが、Actions・Hooks・Custom DB Action・Lock JS ウィジェットへの依存が深いほど抜け出しにくいという報告が多い。2024-2026には Auth0 → Keycloak、Auth0 → Clerk への移行事例が複数公開された。

第15章 · Okta Workforce と Customer Identity Cloud

**Okta** はマネージドIdPのもう一極だ。2022年8月の LAPSUS$ 侵害、2023年10月のサポートシステム侵害を経て、Oktaはセキュリティ運用を大きく強化した。

**Workforce Identity Cloud(WIC)** は従業員向けIdP。

- SAML/OIDC SSO、MFA、Adaptive Auth

- **Lifecycle Management** — HR/HRIS → Okta → SaaS の自動プロビジョニング

- **Workflows** — ノーコード自動化(BambooHR イベントで Slack/GitHub アカウントを自動生成)

- **Identity Governance** — Access Certification、SoD、Access Requests

**Customer Identity Cloud(CIC)** は Auth0 買収を受けて統合された顧客向けIdP。実体としては Auth0 を Okta ブランドで束ねたもの。

企業の90%がOktaを使うスロットは**Workforce + SaaS統合**領域だ。100人以下なら価格が痛い。数百人以上ならSCIMとWorkflowsの価値が価格を正当化する。

第16章 · AWS Cognito — User Pools、Identity Pools、そして機能廃止騒動

**AWS Cognito** はAWSネイティブのIdPだ。二つのスロットがある。

| 構成要素 | 役割 |

| --- | --- |

| User Pools | OIDC互換IdP。ユーザーディレクトリ + ログイン |

| Identity Pools | AWS資格情報を発行。STSトークンで S3/DynamoDB に直接アクセス |

長所は明快だ。AWS内ではほぼ無料の運用費、AWS SDK と IAM との統合が滑らか。

短所も明快だ。2024-2025の間にCognitoが一部機能を廃止・再構成し、大きな論争になった。代表例二つ。

1. **Custom Email Sender Lambda** と SMS/MFA フローの一部でセマンティクスが変わった。

2. **Hosted UI** のOIDC標準適合性に既知のギャップが多数報告されている。`nonce` 検証やリフレッシュトークン回転の挙動など。

もう一つの弱点が**データエクスポート**だ。User Pool のユーザーをパスワードハッシュも含めて他所に移す標準経路がない(可能だが、自前のLambdaトリガと並行移行フローが必要)。「入りやすく出にくい」IdPという評が定着した。

新規プロジェクトでCognitoを選ぶには次の二つに明快に答える必要がある。(1) AWS の中だけで生きるか、(2) Hosted UI のギャップに耐えられるか。

第17章 · Microsoft Entra ID — 旧 Azure AD、そして External ID

**Microsoft Entra ID**(2023年に Azure AD からリブランド)は事実上世界最大のIdPだ。Office 365・Microsoft 365・Windows ドメインがすべて Entra ID に紐づいている。

主要機能:

- **Conditional Access** — 条件付きアクセスポリシー。ユーザー/デバイス/ネットワーク/リスクを基にMFAやブロックを判定。

- **Privileged Identity Management(PIM)** — 管理者権限を時間制限で有効化。Just-In-Time admin。

- **Identity Protection** — リスクスコアに基づく異常行動検知。

- **Microsoft Authenticator** + **Passkey** サポート。

**Entra External ID** は2024年に始まったCIAM(顧客向けIAM)サービス。従来の Azure AD B2C が事実上別ラインとして切り離され、External ID がその後継となる。

エンタープライズでEntraがデフォルトなのはライセンスが理由だ。Microsoft 365 にバンドルされているため、追加費用なしでSSOの基本セットがついてくる。短所はマルチクラウド/マルチベンダー環境で Microsoft 依存が深まる点。

第18章 · Google Cloud Identity、Workspace SSO、そして新興SaaS IdP勢

**Google Cloud Identity / Workspace SSO** — Google が職場ドメインのIdPになる。Workspace を使う会社は SAML SP を登録すれば即座に Google ログインがSSOとして使える。

新興SaaS IdPは2020年代に次のように分化した。

| 製品 | スロット | 特徴 |

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

| Stytch | API-first 認証 | SDK、Magic Link、Passwordless が強い |

| FusionAuth | 自己ホスト可 | 単一バイナリ、価格が明快 |

| WorkOS | B2B SSO ゲートウェイ | SAML/OIDC アダプタを委任 |

| Frontegg | B2B マルチテナンシー | UI、Org、SCIM をパッケージ化 |

| Clerk | React/Next.js 親和 | SDKとコンポーネントが洗練 |

| Logto | OSS + マネージド | 開発者体験最優先 |

| SuperTokens | 自己ホスト重視 | OAuthとセッショントークン両モード |

共通項は**開発者体験(DX)**を看板の差別化点に据えたこと。コンソール、SDK、コンポーネント、ドキュメントがAuth0より軽く速く立ち上がる。代わりにエンタープライズガバナンス(Audit、Lifecycle、IGA)はOktaやEntra IDほど深くない。

第19章 · Auth.js、Lucia、better-auth、Clerk — ライブラリ勢

マネージド・自己ホスト型IdPとは別に、「**フレームワーク内でIdPをコードで書く**」方向がある。

**Auth.js v5**(以前のNextAuth.js)は2024-2025の間に Next.js App Router に合わせて v5 へ再設計された。70以上のOAuth/OIDCプロバイダ、多数のデータベースアダプタ、Edge runtime サポート。

// auth.config.ts - Auth.js v5 例

export const { handlers, signIn, signOut, auth } = NextAuth({

providers: [GitHub],

})

**Lucia v3** はヘッドレスセッションライブラリ。2024年の v3 ではユーザーが自前で OAuth フローを書く方針が強化された。2025年にメンテナが「Luciaをライブラリではなく**学習資料**として再ポジショニングする」と発表したのは大きな出来事だった。

**better-auth**(better-auth.com)は2024年に出た新しいライブラリ。Luciaの「自分で書く」と Auth.js の「フレームワーク統合」の中間を狙う。プラグイン構造が強い。

**Clerk** はマネージドSaaSだが、React/Next.js コンポーネント(`<SignIn />`、`<UserButton />`)を前面に出してライブラリのように使える。Organizations、B2Bマルチテナンシー、Passkey、Webhookすべてよく整っている。

選択ガイド:

- ユーザーディレクトリ・管理コンソールが必要 → マネージド(Clerk、Auth0)または自己ホスト(Keycloak)。

- コード制御を最後まで持ちたい → Auth.js / better-auth。

- 学習目的で自前で書く → Lucia のドキュメント。

第20章 · 認可の新時代 — OPA、OpenFGA、SpiceDB、Permify

2026年の大きな変化の一つは**認証と認可の分離**だ。IdPが認証を担い、認可は別エンジンが持つ。

**OPA**(Open Policy Agent、CNCF Graduated)は 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**(2022年に Auth0 が OSS 化、CNCF Sandbox)と **SpiceDB**(Authzed)は **Google Zanzibar** 論文に基づく ReBAC(Relationship-Based Access Control)エンジンだ。

Zanzibarの直感は単純だ。あらゆる権限を「ユーザー — リレーション — オブジェクト」のタプルで表す。

Zanzibar タプル例

user:alice member organization:acme

group:eng member organization:acme

user:bob member group:eng

document:doc1 viewer group:eng

`user:bob` は `document:doc1` を閲覧できるか? `bob` が `eng` のメンバーで `eng` が `doc1` の viewer なので yes。このグラフ走査をミリ秒で処理するのが Zanzibar 系エンジンの本業だ。

**Permify** は同じ方向のもう一つのOSS。Go 製、直感的なスキーマDSL、複数データストア対応。

この潮流の本質は**権限決定をアプリケーションコードから引き離すこと**だ。権限ロジックがコードに散らばれば変更ごとに再デプロイが必要で監査も難しい。エンジンを外部化すればポリシー自体がデータ/設定になる。

第21章 · 韓国と日本のSSO事情

**韓国**。

- **Naver Cloud IAM** — Naver Cloud の自社IAM。SAML 2.0 IdP 役を担える。

- **Kakao i Identity** — Kakao Enterprise が提供する企業向け IAM/SSO。

- **KT Cloud SSO** — KT の SAML/OIDC IdP。公共・金融顧客が多い。

- **SK ICT-IAM** — SK グループ内 IAM 標準化の流れ。

- **政府 GovWAY / GPKI** — 公共機関向け SSO・証明書フレームワーク。

- **民間金融証明書、Toss Auth、PASS** — 本人確認用。SSOとは性質が違うがKYC段階で結合する。

エンタープライズでは Okta・Entra ID が大企業を中心に進入し、Keycloak・Authentik が中堅・スタートアップの自己ホストスロットを占める。NHN Cloud、Kakao i など韓国のクラウドが自社SSOを強化する動きも明確だ。

**日本**。

- **Trust IdP**(国立情報学研究所、NII)— 学術・研究機関向け SAML フェデレーション。

- **Cybozu Office / Cybozu KUNAI** — サイボウズの企業向けSSO。

- **NTT Communications IDPro** — NTTが運営するマネージドIdP。

- **OpenAM**(ForgeRock のOSSフォーク)— 日本のOSSコミュニティを中心に保守継続。

- **TrustLogin**(GMO)— 日本のSaaS向けSSOアグリゲータ。

- **HENNGE One** — 日本市場のSSO/メールセキュリティソリューション。日本ローカルSaaSとの統合が厚い。

日本市場は ForgeRock(OpenAM)資産が厚く、Microsoft 365・Google Workspace をそのままIdPとして使う比率が高い。HENNGE Oneは日本ローカルSaaSとのSAMLアダプタが豊富で、「自社でIdPを建てたくない会社」のデフォルトになる。

第22章 · 移行とロックイン — ForgeRock・Auth0・Cognitoの教訓

**ForgeRock → Ping Identity** — 2023年8月に Thoma Bravo が ForgeRock と Ping Identity の統合を完了し、二つのプロダクトラインが統一ロードマップに乗った。以後 ForgeRock の一部機能が段階的に整理されたり Ping の同等機能に吸収されたりして、既存顧客の移行負担が顕在化した。

**Auth0 ロックイン** — 前章でも触れた通り、Actions/Rules/Custom DB Action への依存が深いほど抜け出しにくい。移行戦略は一般に(1) Auth0 → Keycloak/Clerk へのダブル書き込み → 段階カットオーバー、(2) パスワードハッシュエクスポート可否で流れが変わる。

**AWS Cognito 機能廃止** — 2024-2025の一部機能変更はユーザー信頼に否定的影響を与えた。新規プロジェクトは Cognito を「AWS-only シナリオ + 単純なユーザーディレクトリ」スロットに限定し、複雑な認証フローが必要なら別IdPを選ぶパターンが増えた。

**Keycloak 18 → 26 移行** — WildFlyベースから Quarkus ベースへの移行は大きな変化だった。18.x 以下から 26.x への移行には(1) DBスキーマ自動マイグレーション、(2) ビルド段階の変化(`kc.sh build`)、(3) 一部 SPI インタフェース署名変更への対応が必要だった。LTSサイクルに沿って 26.0 か 26.1 に一度定着させるのが標準的推奨。

移行の一般原則は次の三つ。

1. **標準の上にいる** — OIDC、SAML、SCIM のような標準をIdPネイティブ機能より優先する。

2. **パスワードハッシュエクスポート経路**のあるIdPを選ぶ。ないIdPは事実上ロックイン。

3. **イベントログを外部SIEMに流しておく**。IdPを乗り換えても監査トレイルは残る。

結論 — IdPは選択ではなくライフサイクル

本稿は22章にわたるが、結局一行に集約される。

**「認証・認可・プロビジョニング・監査を一つのライフサイクルとして扱えないなら、どんなIdPを導入しても部分的な解にしかならない。」**

小規模チームの推奨出発点。

- マネージドで素早く → **Clerk** または **Auth0**(価格を許容)

- セルフホスト + ガバナンス → **Keycloak 26** 単一ノード + Postgres

- 現代的UIで自己ホスト → **Authentik**

- リバースプロキシゲートウェイ → **Authelia**

- 認可分離 → **OpenFGA** または **SpiceDB**

- ライブラリで開始 → **Auth.js v5** または **better-auth**

エンタープライズの推奨出発点。

- 従業員向け → **Okta WIC** または **Entra ID**(ライセンス活用)

- 顧客向け → **Auth0**、**Okta CIC**、または **Keycloak マルチテナント**

- HR → IdP → SaaS の自動プロビジョニング → **Okta Lifecycle** または **Workato/Tray** + **SCIM**

- ポリシーエンジン → **OPA** または **SpiceDB** を外部認可器に

ツールは変わる。標準はゆっくり変わり、ライフサイクルはほとんど変わらない。だから標準とライフサイクルを先に設計し、その上にツールを乗せよ。

参考資料

- [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)