「SSO対応」の落とし穴：SAML/OIDCを確認しないと失敗する理由

会員サイトや取引先ポータルの基盤を選定する際、デザインやCMS機能の比較は盛り上がりますが、認証（ログイン）要件は「あとで情シスに聞けばいい」と後回しになりがちです。

しかし実務において、この「後回し」は最も危険な落とし穴です。プロジェクト後半で「実はSAML認証が必須だった」「OIDCに対応していないと連携できない」と発覚した瞬間、それまで検討した候補がすべて白紙に戻り、大幅な手戻りが発生するからです。

本記事では、Web担当者が最低限押さえるべきSSO（SAML/OIDC）の考え方と、基盤選定で失敗しないためのチェック項目を整理します。

カタログや製品資料に「SSO対応」と書かれていても、その実態は製品によって様々です。以下の3パターンがあることを理解しておきましょう。

1. 簡易的なSSO（見た目だけ）：ログインURLをまとめたランチャー機能に近いもの
2. 限定的なID連携：特定のSNSやサービスとは連携できるが、社内基盤とは繋がらないもの
3. 標準プロトコル対応：SAMLやOIDCなど、標準的な規格に対応しているもの

ここを曖昧なまま進めると、導入後に「求めていたSSOではなかった（社内規定を満たせない）」という事態に陥ります。必ずどの方式（プロトコル）に対応しているかまで確認することが重要です。

単に「ログインが楽になる」という利便性だけでなく、多くの企業では統制・セキュリティの観点からSSOが必須要件となります。

• 取引先・代理店向け：企業ユーザーとして安全にアクセスさせたい。
• 社内統制（ガバナンス）：社内のID基盤（Microsoft Entra IDなど）で一元管理したい。
• 退職・異動時のリスク管理：ID基盤側で無効化すれば、即座にログインできなくしたい（権限の即時剥奪）。
• 監査対応：「誰がいつ何をしたか」の証跡を確実に残したい。

つまりSSOは、企業のセキュリティポリシーを守るための命綱として要求される機能なのです。

技術的な詳細はエンジニアに任せるとしても、選定判断のために以下の違いだけは押さえておきましょう。

SAML（サムル）

• 古くからエンタープライズ（大企業）で使われる信頼性の高い方式
• B2Bポータルや社内システム連携で求められることが多い

OIDC（OpenID Connect）

• モダンなWebサービスやアプリで扱いやすい方式
• スマホアプリや複数サービス間の連携でよく使われる

重要なのは「どちらが優れているか」ではありません。連携先（顧客・取引先・自社情シス）がどちらを要求しているかです。ここが明確になると、選定すべき会員基盤はおのずと絞られます。

“後戻り”という最悪の事態を防ぐため、RFP（提案依頼書）や要件定義の初期段階で以下の項目を確認してください。

認証（SSO）チェック

• SSOは必須要件か？（必須 / できれば / 不要）
• 連携方式の指定はあるか？（SAML / OIDC）
• IDプロバイダ（親となるID管理システム）は何か？
• 多要素認証（MFA）は必要か？
• 退会・停止時に即時無効化できる仕組みはあるか？

権限チェック（運用で躓きやすい点）

• ロール（役割）は何種類必要か？（一般 / 管理者 / 代理店 / 承認者 等）
• 組織階層の管理は必要か？（企業 ＞ 部署 ＞ 担当者）
• 独自の承認フローは必要か？

ログチェック（監査対応）

• 操作ログの保存は必要か？（期間は何年か？）
• 監査に耐えうる「改ざん防止」が必要か？
• 具体的にどの操作（閲覧、ダウンロード、編集）を残す必要があるか？

この3点（認証・権限・ログ）を固めるだけで、安価なSaaSで対応できるのか、それとも柔軟なスクラッチ開発や高機能なパッケージが必要なのかの判断がつきます。

会員サイトにおいてUI/UX（使いやすさ・デザイン）が重要であることは間違いありません。
しかし、UXだけで基盤を決めてしまうと、見た目は理想的ですが、セキュリティ要件を満たせず導入不可という結末になりがちです。

手戻りを防ぐための現実的な検討順序は以下の通りです。

1. 認証（SSO）：そもそもログイン・連携できるか？
2. 権限（ロール・組織）：複雑な商流に対応できるか？
3. ログ（監査）：会社の規定をクリアできるか？
4. 連携（基幹/API）：データがつながるか？
5. UX（自由度と改善頻度）：使いやすいか？

UXを軽視するわけではありません。「できない条件（＝技術的な制約）」を先に潰してからUXの比較に入る方が、結果的にプロジェクトはスムーズに進み、理想のサイト構築に近づけます。

SSOやセキュリティ要件は「必要になってから考える」と、その時点で選択肢が消えたり、システム構造の根幹から作り直しになったりと、プロジェクトにとって大きなリスク要因となります。

もし現在、「取引先ポータルを作りたいが、SSO要件の詰め方がわからない」「検討中のSaaSで本当に自社の要件を満たせるか不安」といった状況であれば、まずは認証・権限・ログの要件棚卸しからご支援可能です。 手遅れになる前に、まずは ログインするユーザー種別（社内/取引先/一般）だけでも共有いただき、ご相談ください。