会員サイトの認証設計の基礎──ログイン・SSO・認証基盤は何をどう決めればいいのか

結論の要約

会員サイトの認証設計で最初に決めるべきは、認証基盤をどこに置くかです。選択肢は3つ。①CMSやパッケージに内蔵された認証機能をそのまま使う(安いが拡張性がない)、②クラウドに専用の認証基盤を立てる(Entra ID・Okta・AWS Cognitoなど。サイト追加や連携に強い)、③社内に既にあるオンプレミスの認証基盤(Active Directory/ADFS)と連携する(技術難度が高い)。判断の分かれ目は「サイトが複数あるか、今後増えるか」です。複数サイトの可能性があるなら、専用の認証基盤を整える価値があります。

まず用語を整理する──認証・認可・SSO

認証とは、「あなたは誰ですか」を確認することです。ID・パスワードや多要素認証で本人を特定します。認可とは、本人確認ができた人に対して「あなたは何ができますか」を判断することです。このページは見られる、この手続きはできる、という権限の制御が認可です。認証で本人を確かめ、認可で権限を与える──この2つがログインの裏側で動いています。

認証基盤とは、ユーザーIDとログインを共通で管理する仕組みそのものを指します。複数の会員サイトやECサイトで同じIDを使えるようにする土台です。

よく混同されるのがシングルサインオン(SSO)とセイムサインオンの違いです。セイムサインオンは「同じID・パスワードが使えるが、別のサイトに行ったらもう一度入力が必要」な状態。シングルサインオンは「片方のサイトでログインしていれば、もう片方のサイトに行っても何も入力せずログイン状態になる」ことです。ユーザー体験の差は歴然で、一般に「ID統合」と言うときに目指すのはシングルサインオンです。

設計の最初の論点──認証基盤をどこに置くか

認証設計の実務は、「どの製品を選ぶか」の前に「認証の機能をどこに持たせるか」から始まります。選択肢は3タイプです。

タイプ①：CMS/パッケージ内蔵の認証機能を使う。 DrupalをはじめCMSには認証・認可の仕組みが含まれており、1つのサイトのID・パスワードログインならこれで作れます。最も安く済む選択肢です。弱点は拡張性で、この認証機能を「基盤」として他のサイトやシステムから使うのは現実的ではありません。サイトが1つで完結する前提の選択肢です。

タイプ②：クラウドに専用の認証基盤を立てる。 Entra ID、Okta、PingFederate、AWS Cognitoなどを使い、サイトとは独立した認証基盤を構築します。コストは上がりますが、会員サイトを増やすとき、ECと繋ぐとき、基幹システムと連携するときに圧倒的に有利です。顧客向けの会員基盤では、比較的低コストに構築できるCognitoを軸にする構成も多く使われています。

タイプ③：既存のオンプレミス認証基盤と連携する。 大きな企業では、自社で意識していなくても、全社の認証基盤(Active DirectoryやADFS)を既に持っていることがあります。この場合は新設ではなく連携が論点になりますが、オンプレミスの認証基盤との連携は技術難度が高く、複数のオンプレ基盤が混在しているケースはさらに複雑です。対応経験のあるベンダーが限られる領域だと考えてください。

この3タイプの選択は、そのままコストの選択でもあります。安く作るなら①、しっかり作るなら②、既存資産があるなら③の検討──まずここを決めないと、認証設計は始まりません。

認証基盤を持つメリットは「一度作れば全部に効く」こと

専用の認証基盤を整えるメリットは、SSOの実現だけではありません。

最大の利点は、セキュリティ投資を一箇所に集中できることです。例えば多要素認証は、認証基盤側に一度実装すれば、繋がっているすべてのサイトに効きます。サイトごとに認証の仕組みを別々に作ると、コストが重複するうえ、セキュリティ水準もばらつきます。ID管理も一括化されるため、退会処理や情報変更の運用も効率化されます。

判断の分かれ目──サイトは複数あるか、今後増えるか

では、自社はどのタイプを選ぶべきか。判断の分かれ目はシンプルで、「会員サイト・ECサイトなどのサイトが複数あるか、今後増える可能性があるか」です。

会員サイトとECサイトを連携させたい、第2の会員サービスを構想している、グループ会社のサイトと将来繋ぐかもしれない──こうした可能性が少しでもあるなら、同じIDで使いたくなるのはほぼ確実です。後から認証基盤を整えて統合するのは、最初から基盤を置くより高くつきます。弊社でも、将来の広がりが見えるお客様には、認証基盤をしっかり作る構成をお薦めすることが多いです。逆に、サイトが1つで完結し続けることが明確なら、CMS内蔵の認証で十分です。

まとめ

認証設計の基礎は、認証(誰か)と認可(何ができるか)を押さえたうえで、「認証基盤をどこに置くか」を決めることです。選択肢はCMS内蔵・クラウド専用基盤・既存オンプレ基盤との連携の3つで、分かれ目は「サイトが複数あるか、今後増えるか」。まずは自社のサイトとログインの現状、そして今後3年のサイト計画を一覧にしてみてください。それだけで選ぶべきタイプはかなり絞れます。

認証基盤の方式選定・構成のご相談を承っています。会員サイト構築のご相談はこちら

よくある質問

Q1. 多要素認証(MFA)は必須ですか？

扱う情報によります。決済情報や個人情報の変更手続きがあるサイトでは、実質必須と考えてください。認証基盤を立てる構成なら、MFAは基盤側に一度入れるだけで全サイトに適用できます。

Q2. ソーシャルログイン(Google・LINE等)はどう位置づければいいですか？

登録・ログインの障壁を下げる有効な手段です。認証基盤側でソーシャルログインを受ける構成にすれば、サイトごとの作り込みは不要になります。BtoCでは特に効果的です。

Q3. 認証基盤を作るとしたら、構築期間はどれくらいですか？

基盤単体なら数ヶ月が目安ですが、既存サイトのSSO対応や会員データの名寄せを含めると全体計画次第です。サイト統合まで視野にある場合は、統合の進め方の記事(S8)も併せてご覧ください。

関連記事

• SaaSでは対応できない会員サイトとは？（⑧認証基盤）
• 会員サイトの開発はどこに頼む？