ストーリー
田
田中VPoE
認証と認可の設計を学んだ。最後は「フェデレーション」だ。複数のシステム、複数の組織を横断するID連携の仕組みだ
あなた
SSOのことですか？一度ログインすれば全部のシステムにアクセスできるやつですよね
あ
田
田中VPoE
SSOはフェデレーションの一つの形だ。だが、PayConnectのようなBtoB SaaSでは、もう一つ重要なフェデレーションがある。「エンタープライズSSO」— 顧客企業のIdP（Azure ADやOkta）との連携だ
あなた
顧客企業の社員が自分たちのIdPで認証してPayConnectにアクセスする、ということですか
あ
田
田中VPoE
そうだ。エンタープライズ顧客の多くは「自社のIdP以外でのログインを許可しない」というポリシーを持っている。SAML/OIDC連携に対応していないBtoB SaaSは、大企業への販売で大きなハンデを負うことになる
フェデレーションの概念
フェデレーションとは
フェデレーションの基本構造:
SP（Service Provider）: サービス提供者（PayConnect）
IdP（Identity Provider）: ID提供者（顧客企業のAzure AD等）
フロー:
[ユーザー] ──→ [SP: PayConnect]
│
│ 「認証はIdPにお任せ」
│ （SAML/OIDC リダイレクト）
↓
[IdP: 顧客のAzure AD]
│
│ ユーザー認証（パスワード + MFA）
│
│ アサーション/トークン発行
↓
[SP: PayConnect]
│
│ トークン検証 → セッション作成
↓
[ユーザー] ← アクセス許可SAMLとOIDCの比較
| 観点 | SAML 2.0 | OIDC（OpenID Connect） |
|---|---|---|
| プロトコル | XMLベース | JSONベース（OAuth 2.0拡張） |
| トークン形式 | SAML Assertion（XML） | ID Token（JWT） |
| 主な用途 | エンタープライズSSO | Web/モバイルアプリ、API |
| 歴史 | 2005年〜、成熟 | 2014年〜、急速に普及 |
| 複雑度 | 高い（XML署名、暗号化） | 低い（JSON、JWT） |
| モバイル対応 | 不向き | 優れている |
| 採用状況 | 大企業のエンタープライズIdPで広く採用 | 新しいサービスでは標準 |
「BtoB SaaSを提供するなら、SAMLとOIDC両方に対応すべきだ。大企業はSAMLを要求することが多い。新しいIdPはOIDCをサポートしている」 — 田中VPoE
エンタープライズSSOの実装
SAML SSO の設定項目
| 項目 | SP側（PayConnect） | IdP側（顧客Azure AD） |
|---|---|---|
| Entity ID | https://payconnect.com/saml/metadata | https://sts.windows.net/{tenant-id}/ |
| ACS URL | https://payconnect.com/saml/acs | — |
| SLO URL | https://payconnect.com/saml/slo | — |
| 証明書 | IdPの公開鍵証明書をインポート | SPのメタデータをインポート |
| NameID | emailAddress | user.mail |
| 属性マッピング | firstName, lastName, role | Azure ADの属性 |
OIDC SSO の設定
// Auth0 でのエンタープライズOIDC接続設定例
const enterpriseConnection = {
name: "customer-corp-oidc",
strategy: "oidc",
options: {
client_id: "customer-provided-client-id",
client_secret: "customer-provided-client-secret",
discovery_url:
"https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration",
scopes: "openid profile email",
// 属性マッピング
attributeMap: {
email: "email",
name: "name",
groups: "groups", // ロールマッピング用
},
},
};マルチテナントSSO設計
マルチテナントSSO設計パターン:
テナント識別方法:
1. ドメインベース: user@customer.com → テナントA
2. サブドメインベース: customer.payconnect.com → テナントA
3. ログイン画面で選択: 「組織を選択してください」
認証フロー:
[ユーザー] ──→ PayConnect ログイン画面
│
│ メールアドレス入力: user@customer.com
│
│ ドメイン「customer.com」を検索
│ → テナントAのSSO設定を発見
│ → SAML/OIDCリダイレクト
↓
[顧客のIdP]
│
│ 認証 + MFA
│
↓
PayConnect
│
│ アサーション検証
│ テナントA + ロールマッピング
│ セッション作成
↓
[ユーザー] ← テナントAのダッシュボードにアクセスプロビジョニングとデプロビジョニング
SCIM（System for Cross-domain Identity Management）
SCIM によるユーザーの自動プロビジョニング:
IdP（Azure AD） PayConnect（SP）
│ │
│ 新入社員追加 │
│ ──── SCIM CREATE ────→ │ ユーザー自動作成
│ │
│ 部署異動 │
│ ──── SCIM UPDATE ────→ │ ロール自動変更
│ │
│ 退職 │
│ ──── SCIM DELETE ────→ │ ユーザー無効化
│ │ + セッション即時終了
│ │ + APIキー失効デプロビジョニングの重要性
| リスク | 対策 |
|---|---|
| 退職者のアカウントが残存 | SCIMによる自動デプロビジョニング |
| 退職者のセッションが有効 | アカウント無効化時にセッション即時失効 |
| 退職者のAPIキーが有効 | アカウント無効化時に全APIキーを失効 |
| 退職者のシークレットアクセス | Vaultのエンティティを無効化 |
SSOの可用性設計
IdP障害時の対応
| シナリオ | 影響 | 対策 |
|---|---|---|
| 顧客のIdPがダウン | 該当テナントのユーザーがログイン不能 | ローカルアカウントへのフォールバック（管理者のみ） |
| SAML証明書の期限切れ | SSO認証エラー | 証明書の自動監視 + 30日前アラート |
| IdPのメタデータ変更 | SSO認証エラー | メタデータの定期取得 + 変更検知 |
「SSOに依存するということは、IdPの障害があなたのサービスの障害になるということだ。必ずフォールバック手段を用意しておけ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| フェデレーション | 複数のシステム/組織を横断するID連携の仕組み |
| SAML vs OIDC | 大企業はSAML、新しいサービスはOIDC。BtoB SaaSは両対応が必要 |
| マルチテナントSSO | ドメインベースのテナント識別 + IdP連携 |
| SCIM | ユーザーの自動プロビジョニング/デプロビジョニング |
チェックリスト
- SAMLとOIDCの違いを説明できる
- マルチテナントSSOの設計パターンを理解した
- SCIMによる自動プロビジョニングの仕組みを理解した
- IdP障害時のフォールバック戦略を把握した
次のステップへ
次は演習です。PayConnectシステムのID管理基盤を設計しましょう。
推定読了時間: 30分