あなたの製品を気に入った最初のエンタープライズ顧客は、いずれ価格より難しい質問を投げかけてくる。
顧客企業のセキュリティチームは、自社のアイデンティティプロバイダー経由のシングルサインオン、退職者が出た際の自動的なアカウント停止、そして誰がいつアクセス権を持っていたかを示す証跡を求める。
その答えがまだ「対応を計画中です」なら、慌てて対応する間に商談が四半期分ずれ込むことも珍しくない。
私はそのレビューの両側を経験してきた。以下は、質問票が届く前に成長中のB2B SaaSチームが整えておくべき、オープン標準を軸にしたアイデンティティチェックリストだ。
エンタープライズのセキュリティチームが実際に尋ねる質問
「SSOに対応していますか？」だけではない。一般的な質問票には、次のような項目が含まれる。
- 従業員はSAML 2.0またはOpenID Connect（OIDC）を使って、当社の企業向けアイデンティティプロバイダー経由でサインインできますか？
- 当社のIdPでMFAを強制できますか。また、別のMFA経路を勝手に追加せず、そのシグナルをアプリケーションで尊重できますか？
- ユーザーのプロビジョニングとデプロビジョニングはどのように行いますか？SCIMに対応していますか？
- セッションの有効期間、リフレッシュトークンのポリシー、アイドルタイムアウトはどうなっていますか？
- 認証ログや管理者イベントログをSIEMにエクスポートまたはストリーミングできますか？
- 当社のテナントのデータ、設定、アイデンティティ接続を、他のすべての顧客からどのように分離していますか？
- 貴社のスタックでアイデンティティインシデントが発生した場合、どのように当社へ通知し、認証情報をローテーションし、影響を受けたアカウントを証明しますか？
それぞれに具体的な仕組みで答えよう。「セキュリティを重視しています」という回答では、相手のIAMアーキテクトとのフォローアップの電話を乗り切れない。
SAMLとOIDCの基礎
エンタープライズの購入担当者の多くは、すでにSAML 2.0をワークフォース向けIdPに組み込んだ状態でやって来る。OIDCは、モダンなクラウドIdP、APIを多用する製品、モバイルクライアントで使われることが多い。多くのSaaS製品は両方に対応し、テナントごとに選べるようにしている。
セットアップはメタデータの交換だ。
- SAML： エンティティID、アサーションコンシューマーサービスURL、シングルログアウトエンドポイント、署名証明書を顧客と交換する。
- OIDC： 発行者URL、クライアントIDとシークレット（またはパブリッククライアント設定）、リダイレクトURI、ディスカバリードキュメントの場所を交換する。
最初の接続を本番稼働させる前に、証明書と署名鍵のローテーションを計画しておこう。IdP証明書の期限切れは、本番環境でよくある障害だ。
SP起点フローとIdP起点フローの違いを把握しておこう。
- SP起点： 自社アプリから始まり、IdPへリダイレクトする。ディープリンクや招待では通常この経路を使う。
- IdP起点： 顧客のアプリポータルから始まり、未承諾のアサーションまたはログイン情報とともに自社アプリへ到達する。
購入者側のポータルチームがアプリカタログ内のタイルを想定しているなら、両方に対応しよう。
属性とクレームのマッピングには、気づきにくい障害が潜んでいる。グループ名、メールアドレス、部署属性はIdPごとに異なる。テナントごとに明示的にマッピングしよう。
必須クレームが欠落している場合は、フェイルクローズにする。上流でグループ属性の名前が変更されたからといって、デフォルトの管理者ロールやメンバーロールにフォールバックしてはならない。
テナント分離
エンタープライズSSOは本質的にマルチテナントだ。顧客ごとに独自のIdP接続、独自のドメインリスト、独自の属性マップが必要になる。
ドメイン検証（またはホームレルムディスカバリー）によって、user@customer.comを共有ログインページではなく、その顧客のIdPへルーティングする。
すべてのトークンとセッションに安定したテナント識別子を含め、すべてのリクエストでオーディエンスと併せて検証する。Tenant A向けに発行されたトークンで、ユーザーのメールアドレスが一致していてもTenant Bのデータを開けてはならない。
さらに、APIごとのオーディエンス値（使用している場合はRFC 8707のリソースインジケーターを参照）を組み合わせ、請求処理向けのトークンで管理APIを呼び出せないようにする。
関係のない顧客間で共有する「キャッチオール」IdP接続は避けよう。共有接続では属性マッピングが曖昧になり、1つの設定ミスがテナント間インシデントに発展する。
オフボーディングとSCIM
SSOだけでは、退職した従業員が再びサインインするのを止めるだけだ。製品内にすでに存在するアカウントや、そのアカウントが保持するAPIキー、パーソナルアクセストークン、リフレッシュトークン、長期間有効なセッションまでは削除されない。
SCIM 2.0（スキーマはRFC 7643、プロトコルはRFC 7644）を使うと、顧客のディレクトリから自社アプリ内のユーザーを自動的に作成、更新、無効化できる。
人事部が退職処理を行うと、IdPは無効化通知を送信する。自社アプリでは同じワークフロー内で、ユーザーを無効化し、リフレッシュトークンとセッションを失効させ、そのアイデンティティに紐づくAPI認証情報を無効にするべきだ。
ジャストインタイム（JIT）プロビジョニングでは、初回のSSOログイン時にアカウントを作成する。初期段階のテナントやデモには適しているが、それだけではオフボーディング、ロール変更、シートの整理には対応できない。
顧客に本格的なIT機能があるなら、SCIM（または同等のディレクトリ同期）を優先しよう。JITしか提供しない場合は、その不足を正直に文書化することだ。購入者はそこを尋ねてくる。
トークンの有効期間と失効については、OAuthのセキュリティベストプラクティス（RFC 9700）に従おう。短期間で失効するアクセストークンと、失効可能なリフレッシュトークンを組み合わせれば、SCIMが「無効化済み」と通知した際に実効性のある停止スイッチを持てる。
監査証跡
セキュリティ質問票やSOC 2、ISO 27001に準拠したレビューでは、誰が認証したか、誰がロールを変更したか、誰がIdPを接続したか、誰がデータをエクスポートしたかが問われる。
ログインイベント、管理者イベント、プロビジョニングイベントについて、タイムスタンプ、実行者、対象、テナント、可能な場合はIPまたはデバイスのコンテキスト、結果を記録する必要がある。
保持期間は購入者の業界で期待される水準に合わせ、エクスポートは1週間分のエンジニアリング作業なしで生成できるものにする。CSVまたはJSONのダウンロードは小規模な購入者に役立つ。SIEMへのストリーミングは、Webhookまたはログシップ経由で大規模な購入者を支援できる。
「このテナントにこの2つの日付の間にアクセスできたのは誰か、見せてください」という問いに答えられるようにしておこう。その検索にデータベース考古学者が必要なら、監査人に尋ねられる前にロギングを改善すべきだ。
AIエージェントの位置づけ
AIエージェントやMCP型のツール連携は、ユーザーに代わって製品内で動作する機会が増えている。これらをアクセスモデルにおける第一級のアイデンティティとして扱う。
スコープが設定され、短期間で失効し、エージェントが呼び出せるAPIに対してオーディエンスが限定された委任OAuthトークンを優先しよう。すべてのログ行で、人間のユーザーのアイデンティティとエージェントのアイデンティティを区別できるようにする。
ユーザーを失効させる際は、そのユーザーの下で発行されたすべてのエージェント付与、リフレッシュトークン、ツール認証情報も失効させる。それを怠ると、UI上ではオフボーディングが完了しているのに、エージェントが有効なトークンを保持し続けることになる。
内部APIを保護するのと同じオーディエンスの規律が、ここでも適用される。すべてのエージェントツールで共有する広範なオーディエンスは、いずれか1つの連携からトークンが漏れた瞬間にマスターキーと化す。
締めくくりのチェックリスト
次のエンタープライズ向け質問票に回答する前に、以下の項目をすべて確認できるか確かめよう。
- メタデータ交換と証明書ローテーションを文書化した、テナントごとのSAML 2.0および／またはOIDC接続。
- 少なくとも1つの実在顧客のIdPでテストした、SP起点とIdP起点のログイン経路。
- 明示的な属性・クレームマップと、マッピングされたクレームが欠落した場合のフェイルクローズ動作。
- ユーザーを正しいIdPへルーティングするドメイン検証またはホームレルムディスカバリー。
- トークン内の安定したテナントIDと、すべてのリクエストでオーディエンスと併せて行う検証。
- セッション、リフレッシュトークン、API認証情報を失効させるSCIM 2.0（または同等の仕組み）によるデプロビジョニング。
- SOC 2に準拠したレビューで説明できる保持期間を備えた、エクスポート可能な認証・管理者イベントログ。
- エージェントとツールのアクセスを、明確に区別できるログ上のアイデンティティを持つ、委任されたスコープ付きの失効可能なトークンとしてモデル化すること。
エンタープライズSSOは、ログイン、認可、ライフサイクル、監査、そして今や非人間アクターにも関わる。購入者がまだミッドマーケットにいるうちにこれらの要素を構築しておけば、最初の本格的なセキュリティレビューは、契約上のプレッシャーの下での再構築ではなく、スケジュールについての話し合いになる。
続きを読む：認証、アクセス、アイデンティティのライフサイクルを管理する最適なアイデンティティ・アクセス管理ソフトウェアを詳しく見てみよう。