SSOとアイデンティティプロバイダー2026完全ガイド - Keycloak 26 · Authentik · Authelia · Auth0 · Okta · AWS Cognito · Microsoft Entra ID 深掘り

プロローグ — 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を「一度ログインすれば済むこと」と理解すると本質を見落とす。実際の問題は四層構造だ。

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

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

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

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

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がアサーションを検証してセッションを作る。

<!-- 簡略化したSAML Response抜粋 -->
<samlp:Response>
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status>
  <saml:Assertion>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
        alice@example.com
      </saml:NameID>
    </saml:Subject>
    <saml:Conditions NotBefore="..." NotOnOrAfter="..."/>
    <saml:AttributeStatement>
      <saml:Attribute Name="memberOf">
        <saml:AttributeValue>engineering</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

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

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

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

主要エンドポイント:

{
  "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を最初に触るとき混乱するのは語彙だ。

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 の複数モジュールのまとまりだ。

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だ。二つのスロットがある。

長所は明快だ。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年代に次のように分化した。

共通項は**開発者体験(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 例
import NextAuth from "next-auth"
import GitHub from "next-auth/providers/github"

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
• Keycloak 26 Release Notes
• Red Hat build of Keycloak
• Authentik Documentation
• Authelia Documentation
• Casdoor Documentation
• Ory Documentation
• Logto Documentation
• Auth0 Documentation
• Okta Developer Documentation
• AWS Cognito Developer Guide
• Microsoft Entra ID Documentation
• Microsoft Entra External ID Overview
• OAuth 2.1 Draft
• OAuth Security BCP
• OpenID Connect Core 1.0
• WebAuthn Level 3 (W3C)
• FIDO Alliance Specifications
• SCIM 2.0 RFC 7644
• SAML 2.0 OASIS Standard
• Open Policy Agent
• OpenFGA Documentation
• Authzed SpiceDB
• Permify Documentation
• Auth.js v5 Documentation
• Lucia Auth
• better-auth Documentation
• Clerk Documentation
• HENNGE One
• Naver Cloud IAM