SAML SSO は『B2B SaaS の通行手形』
大企業向けに SaaS を提供する際、SAML SSO 対応は事実上の必須要件です。本記事では編集部の視点で、SAML 実装の要点を公開情報をもとに整理します。OAuth/OIDC 実装 もご参考に。
SAMLとOIDCの使い分け
(1) SAML：エンタープライズ・既存IdP 連携。XML ベース。(2) OIDC：モダンWeb・モバイル・SPA。JSON ベース。(3) 事実上の標準：B2B SaaS は両対応が増加。(4) SSO 対応料金：Enterprise プランで提供する企業が多い。(5) 歴史的背景：SAML は2005年頃、OIDC は2014年頃登場。
SAML の登場人物
(1) SP (Service Provider)：あなたのアプリ。(2) IdP (Identity Provider)：Okta/Entra ID/Google Workspace等。(3) SAML Assertion：認証結果を含むXML。(4) Metadata XML：SP/IdP の設定情報。(5) SSO URL / ACS URL：エンドポイントの定義。
SP-Initiated vs IdP-Initiated
(1) SP-Initiated：SP のログインボタンから開始。(2) IdP-Initiated：IdP のダッシュボードから開始。(3) 両対応推奨：エンタープライズで要求される。(4) RelayState：戻り先の情報を保持。(5) SAML Response 検証：署名と有効期限を必ず確認。
実装ライブラリ
(1) node-saml / passport-saml：Node。(2) python3-saml：Python。(3) SAML2 ruby gem：Ruby。(4) Spring Security SAML：Java。(5) SAML SaaS (WorkOS/SSOReady等)：丸ごとマネージド。自前実装より SaaS 利用の方が安全で速い場合が多いです。
JIT プロビジョニング
(1) SAML Response の属性からユーザーを作成。(2) email / firstName / lastName / role を取得。(3) 既存ユーザーの更新：上書き or 部分更新。(4) 役割マッピング：IdP のグループ→アプリ内ロール。(5) SCIM：JIT より厳密な同期(別仕様)。
セキュリティ要件
(1) 署名検証必須：偽造を防ぐ。(2) NotBefore / NotOnOrAfter：有効期限。(3) Audience 制限：自分のアプリ向けか確認。(4) InResponseTo：認可リクエストとの対応。(5) HTTPS 必須：HTTP は許容しない。Webセキュリティ実践 もご参考に。
失敗しがちなパターン
(1) 署名検証を省略：致命的脆弱性。(2) RelayState の値検証なし：オープンリダイレクト。(3) 属性名のIdP依存：顧客ごとに対応大変。(4) セッション分離なし：複数テナントで権限漏れ。(5) SLO 未対応：エンタープライズ要件で必要。対策は、(1)ライブラリ任せ+テスト、(2)許可リスト方式、(3)Common Attribute マッピング、(4)テナント分離、(5)Single Log-Out 実装、です。