はじめに
こんにちは！入社1年ちょっとのkenkenです。
先日、同じPMの仲間としてフレッシュな新人・ひろきさんが入社しました。ついこの間まで「新人」を言い訳にできた身としては、いよいよ先輩らしいところを見せなければ…と静かに背筋が伸びています。というわけで、今日も張り切って書いていきます！
前回の記事「CIAMとは？」で、顧客向けのIDは自社社員向けのIDとは別レイヤーで考えるのが基本、というお話をしました。すると次に来るのが、この相談です。
「で、うちのサービスの認証基盤、結局何で作ればいいの？」
結論から先にお伝えすると、自社サービスの認証基盤の実現方法は、大きく3つの選択肢があります。
- (1) フレームワーク・ライブラリの認証機能を使う（アプリに組み込む）
- (2) 認証サーバーを自社で運用する（例：Keycloak）
- (3) CIAMサービスを使う（例：Auth0、Entra External ID）
どれかが正解でどれかが不正解、という話ではありません。選び方の軸はひとつで、「認証基盤の仕様追従とセキュリティ運用の責任を、どこまで自社で持つか」です。そして責任を持てるかどうかの基準は「作れるか」ではなく、「作った後、維持し続けられるか」。作ること自体は、いまではどの選択肢でも難しくありません。難しいのは、攻撃の進化と仕様の変化に、サービスが続く限り追従し続けることです。
この記事では、3つの選択肢を地図として整理し、どの選択肢でも発生する「背負うものリスト」を共通の物差しにしたうえで、自社の要件を当ててどれがフィットするかをPM目線で整理していきます。
そもそも：認証基盤の実現方法を地図にする
まず選択肢の全体像です。「責任をどこまで自社で持つか」の軸で並べると、こうなります。
| 選択肢 | 実現方法 | 例 | 認証の仕様追従・セキュリティ運用の責任 |
|---|---|---|---|
| (1) | フレームワーク・ライブラリの認証機能 | 各種Webフレームワークの認証モジュール | ほぼ自社（ライブラリ更新の追従含む） |
| (2) | 独立した認証サーバーを自社で運用 | Keycloak（OSSのIdP製品） 等 | ソフトは既製、運用・更新は自社 |
| (3) | CIAMサービスを利用 | Auth0、Entra External ID 等 | 基盤部分はベンダー、設定・設計は自社 |
※OSS＝オープンソースソフトウェア、IdP＝Identity Provider（認証を担う基盤）
いくつか補足です。
- (1)フレームワーク・ライブラリの認証機能とは
- フレームワーク（Webサービスを作る土台となる開発キット。例：Django、Laravel）に備わる認証機能や、フレームワークに別途追加する認証ライブラリ（例：Ruby on Railsで使われる Devise）を使い、自社のアプリに組み込んで自前で運用していく形です。「自前で作る」といっても全部を手書きするわけではなく、パスワードのハッシュ化のように作り込みを誤ると事故に直結する部分は、自作せず検証済みのライブラリに任せるのが鉄則です（「暗号は自前で作るな（Don't roll your own crypto）」は開発の世界の定説です）。認証機能を組み込んだうえで、自社サービス独自のログイン画面や会員項目を作っていきます。
- (2)認証サーバーの自社運用とは
- Keycloakのような認証専用のソフトを、自社のサーバーに自分で立てて動かす形です。認証機能がアプリの中の部品として動く(1)と違い、(2)では認証がアプリの外に独立した一台として存在し、アプリはそこに問い合わせます。標準プロトコル（OIDC・SAMLなど）で会話するので特定の言語に縛られず、複数アプリや取引先との連携に向きます。
- (3)の中にも選択肢があります
- CIAMサービスには、大きく2種類あります。ひとつは、Microsoft・AWS・Googleといったパブリッククラウドに付随するCIAM機能（Entra External ID、Amazon Cognito など）を使うパターン。もうひとつは、特定のクラウドには紐づかない独立基盤の「独立CIAM」（Auth0 など）を使うパターンです。どちらが合うかの使い分けは前回の記事で詳しく整理しているので、気になる方はそちらをご覧ください。今回は、この2種類をまとめて(3)CIAMサービスとして扱います。
共通の物差し：どの選択肢でも「背負うもの」は同じ
3つを比べる前に、大事な前提をひとつ。この3つは、どれが優れているという序列ではなく、自前で持つ(1)を含めて、どれも要件次第で正解になります。検索すると「自前実装はやめておけ」という論調をよく見かけますし、自前で維持し続けるハードルが上がっているのも事実です。でもそれは一律の結論ではなく、やはり要件によります。
そしてもうひとつ。認証基盤が満たすべきことの中身は、どの選択肢を選んでも変わりません。変わるのは、そのうちどれだけを自社で持つかです。自社で持つ範囲を狭めれば自社に残る仕事は減りますし、外に出せない要件があるなら、その分は自社で持つことになります。
OWASP（Webセキュリティの国際コミュニティ）やNIST（米国国立標準技術研究所）が公開している中立的な基準（OWASP Authentication Cheat Sheet、NIST SP 800-63-4 など）をベースに、その「仕事」を棚卸ししてみます。
- パスワードの保存と検証
- 適切なハッシュ方式の選定と、方式が古くなったときの移行。漏洩パスワードリストとの照合も推奨されています。
- パスワードリセット
- 「忘れた方はこちら」の裏側です。実はアカウント乗っ取りの主要な攻撃経路のひとつで、メール送信・トークン管理・有効期限の設計をすべて安全に保つ必要があります。
- MFA（Multi-Factor Authentication、多要素認証）
- 認証アプリ・SMS・パスキーなど方式ごとに実装が必要で、さらに方式の位置づけが変わればそれに追従し続ける必要があります（例：SMS認証の位置づけは年々変わっています）。
- セッション管理
- 有効期限、強制ログアウト、複数デバイスの扱いです。ここを正しく保たないと、ログアウトしたはずのセッションが生き続けたり、盗まれたセッションがそのまま悪用されたりします。地味ですが穴になりやすい領域です。
- bot・不正ログイン対策
- 公開された登録・ログインエンドポイントは、bot登録やクレデンシャルスタッフィング（漏洩したID・パスワードの使い回し攻撃）の的になります。レート制限や検知の仕組みが要ります。
- ソーシャルログイン連携
- 各プロバイダーの仕様変更・非推奨化への追従。連携先が増えるほど追従作業も増えます。
- 監査ログ
- 誰がいつログインし、何に失敗したか。社内の監査や、顧客監査・認証取得・法令対応といった社外の監査要件に応えるため、後から必ず必要になります。
- アカウントのライフサイクル管理（特に利用終了時）
- 退会・休眠・契約終了など、利用終了時の削除・無効化の方針と処理です。決め忘れると放置アカウントが積み上がり、乗っ取りやプライバシー対応リスクの温床になります（前回の記事でも見落としポイントとして挙げた論点です）。
- プロトコル・脆弱性への追従
- OAuthやOIDC（OpenID Connect）まわりのベストプラクティスは更新され続けています。「一度作って終わり」にはなりません。
ポイントは、このリストのどれもが「一度作れば終わり」ではなく、作ったあとも運用し続ける負担を伴うことです。(1)ならこの全部を自社で、(2)ならソフト以外を自社で、(3)なら基盤部分をベンダーに任せて設定・設計を自社で持ちます。つまり選択肢選びとは、冒頭の軸のとおり、このリストにある仕様追従とセキュリティ運用の責任を、どこまで自社で持つかの線引きなんです。
コスト構造の違い：どこが見えて、どこが見えないか
もうひとつの物差しがコストです。3つの選択肢は、コストの「見え方」がそれぞれ違います。
- (1) フレームワーク・ライブラリの認証機能：継続コストが見えにくい
- 初期コスト（開発工数）は小さく見えます。見えにくいのは継続コストです。前節のリストへの追従、セキュリティ対応、そしてその知識を持つ担当者を維持し続けること。担当者の異動・退職で属人化リスクが一気に顕在化するのは、よくあることです。
- (2) 認証サーバーの自社運用：運用の負担が見えにくい
- ソフトの調達費用（OSSなら無償、商用製品ならライセンス費用）は事前に分かるので、見積もりに載ります。見えにくいのは、サーバー・バージョンアップ・脆弱性対応といった基盤を動かし続ける運用の負担です。OSSでも商用でも、“自社で運用する”以上、この手間と、それを担える人材の確保は自社に乗ります。
- (3) CIAMサービス：ユーザー急増時のコストの膨らみ方が見えにくい
- 継続コスト（多くはMAU＝Monthly Active Users、月間アクティブユーザー数に応じた課金）は見えます。見えにくいのは、ユーザー数が急に伸びたときのコストの膨らみ方です。しかもユーザーが増えた分だけ比例して増えるとは限らず、料金プランの段階や上位プランへの移行で、増え方はサービスによって変わります。想定ユーザー数と急伸シナリオを、料金体系に当てて事業計画とセットで見積もっておく必要があります。
どれを選ぶにしても、「見えないほう」を先に数字にしておくのが、あとで揉めないコツです。
まず確認：選択を左右する6つの要件
ここが一番気になるところですよね。ただ、前回もお伝えしたとおり、これは「(1)だから◯◯」と選択肢のカテゴリで決められるものではなく、自社の要件を先に整理して、それを選択肢に当てていくのが順番です。というのも、このあとの向き不向きは、全部この要件の当てはまり方から導かれるからです。
見極めるうえで効いてくる要件は、実はそれほど多くありません。次の6つを先に確認しておくと、選択肢がかなり絞れます。
- 自社のセキュリティ基準・認証要件を、外部サービスで満たせるか
- 選定の土台になる確認です。求めるセキュリティ基準や認証要件をSaaSで満たせるなら、コストを払って(3)に任せ、運用を軽くする道が開けます。逆に、外部サービスでは実現できない独自の認証要件があるなら(1)が、データの置き場所や接続の制約で外部サービス自体を使えない領域なら(2)が視野に入ります。
- MFA・パスキー対応は求められるか
- 求められるなら、方式ごとの実装・運用と方式の入れ替わりへの追従が発生します。(1)で足すと負担が一段増える領域です。
- B2Bの取引先から「うちのIdPでSSOさせてほしい」と言われる可能性はあるか
- SAMLやOIDCでの取引先IdP連携は、(1)の想定外になりがちで、営業案件の受注条件になることもあります。(2)(3)の得意領域です。
- ユーザー数の急伸はありうるか（キャンペーン・メディア露出など）
- 認証部分のスケールとbot・不正ログイン対策が同時に問われます。急伸時は攻撃も一緒に増えます。
- 監査・コンプライアンス要件はあるか
- 監査ログの整備、同意管理、削除依頼への対応など。「仕組みとして担保できているか」を外部に説明する場面があるかどうかです。
- 認証まわりを継続して見られる体制はあるか
- 要件ではなく体制の確認です。担当が1人しかいない状態で(1)(2)を選ぶと、その人の異動・退職で「触れない聖域」になり、脆弱性対応が止まるリスクを抱えます。
大まかな傾向としては、要件1で外部サービスを使える前提が立ったうえで、2以降の要件が多く・強く当てはまるほど、責任を外に出す選択肢（(3)側）が合いやすくなります。逆にどれも当てはまらないなら、(1)で小さく持つのが合理的な場面も普通にあります。
つまずきやすいのは、この6つの要件を確認しないまま「いま作りやすいもの」で選んでしまうケースと、「見えないほうのコスト」を数字にしないまま決めてしまうケースです。
要件を当てると、こう絞り込まれていく
6つの要件の当てはまり方を、各選択肢の向き不向きに落とし込むと、だいたい次のようになります。優劣ではなく、あくまで「どの要件が揃うとどこに寄るか」の目安として読んでください。
(1) フレームワーク・ライブラリの認証機能が向いているケース
- 社内限定や限定公開に近いサービスで、ユーザー数の上限が読める。
- 認証要件がID・パスワード程度で固定的（MFA・ソーシャル・取引先連携の予定がない）。
- アプリと認証を同じチームで見られて、担当が1人に依存しない。
- まずは小さく速く始めたい。
- 外部サービスでは満たせない独自の認証要件があり、開発リソースをかけてでも作り込む必要がある。
注意点
- 「背負うものリスト」の全項目を自社で回し続けることになります。体制の継続性が前提条件です。
- MFA・取引先SSO・監査要件など、リストの「その先」の要件が出てきたときに、実装・運用の負担が段違いに増えます。要件の伸び方の見立てが重要です。
- セキュリティインシデント発生時の説明責任も自社に来ます。監査ログや対応体制は最初から設計に入れておく必要があります。
(2) 認証サーバーの自社運用（Keycloak等）が向いているケース
- SSOや取引先IdP連携など標準プロトコルベースの要件はあるが、外部サービスの利用に制約がある（データの置き場所・社内ポリシー等）。
- 基盤運用（サーバー・バージョンアップ・脆弱性対応）を担える運用体制に厚みがある。
- ユーザー数が多く、MAU課金よりも運用の内製化のほうが合理的と試算できる。
注意点
- 「ソフトは既製、運用は自前」の中間形態です。認証機能そのものは手に入りますが、基盤を安全に保つ仕事は(1)と同様に自社に残ります。
- バージョンアップの追従が滞ると、脆弱性を抱えたまま止まる典型パターンに入ります。計画的な更新運用が前提です。
(3) CIAMサービス（Auth0等）が向いているケース
- 求めるセキュリティ基準・認証要件を、SaaSで満たせる。
- 一般公開のサービスで、ユーザー数が変動・成長する。
- MFA・ソーシャルログイン・パスワードレスなどを、段階的に足していきたい。
- B2Bで、取引先ごとのIdP連携（SSO）が受注条件になっている・なりそう。
- 開発リソースを認証基盤ではなく、サービス本体の機能開発に集中させたい。
- 同意管理などのプライバシー要件があり、仕組みとして担保したい。
注意点
- MAU課金の跳ね方は事業計画とセットで見積もる必要があります（前節のとおり）。
- 管理する基盤・契約が1つ増えます。設定や設計の責任は引き続き自社側にあります（「任せたら終わり」ではありません）。
- 乗り換え時のことを最初に確認しておくのがおすすめです。ユーザーデータ（特にパスワードハッシュ）のエクスポート可否は、契約前に見ておきたいポイントです。
ざっくり言うと、閉じた用途・固定的な要件・継続できる体制（または外部サービスでは満たせない独自要件）なら(1)、標準プロトコル要件×外部サービス制約×厚い運用体制なら(2)、公開サービス×伸びる要件×開発リソースの集中なら(3)が合いやすい、という傾向です。
⚠️ ここで挙げたのはあくまで「方向性」です。個別の要件で判断が変わるので、断定的な「自前は無理」「サービスなら安心」という話ではありません。
まとめ：あなたのサービスに合った認証基盤の持ち方は？
自社サービスの認証基盤の実現方法は、(1) フレームワーク・ライブラリの認証機能、(2) 認証サーバーの自社運用、(3) CIAMサービスの3択でした。認証基盤が満たすべきことの中身はどれを選んでも同じで、選択肢選びとは、仕様追従とセキュリティ運用の責任をどこまで自社で持つかの線引きです。判断基準は「作れるか」ではなく「維持し続けられるか」。
選ぶ前に、まずはご自身のサービスの状況を整理してみるのがおすすめです。
- 6つの要件（セキュリティ基準・MFA・取引先SSO・急伸・監査・体制）のうち、当てはまるものはどれか
- 認証基盤を継続的に見られる体制があるか（担当は1人に依存していないか）
- 認証要件は今後どう伸びそうか
- 想定MAUと、急伸したときのコスト試算
- （(3)の場合）ユーザーデータのエクスポート可否の確認
「うちの場合はどれ？」の整理が難しいときは、誰かに相談してみるのもいいかもしれませんね！
フレッシュな仲間がどんどん増えて、会社はどんどん若返っています。平均年齢を引き上げる側に回りつつある事実には一抹の不安を覚えますが、その分の経験値で貢献できるよう、今日も頑張ります！
