## 6. 認証・認可

確認：2026年9月

| ケース | 既定 | 代替と乗り換え条件 |
|---|---|---|
| TSアプリ（自前で持つ） | **Better Auth** | Auth.js：既存プロジェクトのみ（Auth.jsの保守はBetter Authに移管された）。Better AuthはVercelの傘下に入った（OSSでフレームワーク非依存の方針は維持） |
| マネージド（toC・スタートアップ） | **Clerk**（UI込み・最短で導入） | Supabase Auth：Supabase採用時。Firebase Authentication：モバイル中心 |
| マネージド（AWS中心） | **Amazon Cognito** | Auth0：機能とUIを重視し予算があるとき |
| B2BのSSO（SAML／OIDC）・SCIM | **WorkOS** | Auth0（Enterprise機能）：取引先の要件でAuth0が指定されている、またはIdP連携の種類がWorkOSで足りないとき |
| セルフホストIdP | **Keycloak** | Zitadel：軽量・モダンなものが欲しいとき |
| Rails | **Railsの認証ジェネレータ**（§2-3参照） | Devise：OAuth連携・多要素認証など機能を一式揃えたいとき（§2-3） |
| Go | **外部IdPに任せ、アプリはOIDCトークンの検証のみ**（coreos/go-oidc） | — |
| 社内ツール | **Google Workspace／Microsoft Entra IDでのSSO** | — |
| 認可ロジック（複雑な権限） | **アプリ内でポリシーを明示的にコード化**（Pundit、自前） | OpenFGA／SpiceDB：リソース単位の共有・継承が複雑なとき（Googleドライブ型） |
| パスワード以外 | **パスキー（WebAuthn）対応を優先** | — |