BtoB業務システムにおける「多層的な認証フロー」設計事例：なぜ今、認証設計が再注目されるのか？
導入：SaaS普及時代に問われる「認証UX」の品質
SaaS型の業務システムやWebアプリケーションが普及する中で、「認証の仕組み」は単なるセキュリティ対策ではなく、業務の柔軟性や使いやすさを左右するUXの一要素となっています。特に企業向けのWebシステム開発では、「誰がどこまでアクセスできるか」だけでなく、「どのタイミングで、どの認証を求めるか」といったフロー設計が、顧客満足度と直結します。
また、セキュリティ面だけでなく、営業部門やカスタマーサクセス部門が認証を活用して顧客接点をコントロールする場面も増えてきています。そのため、認証設計は「運用体験」の設計とも言えるほど、重要性が高まっています。
本記事では、受託開発の現場で設計・構築した「多層的な認証フロー」の実装事例をベースに、BtoB特有の要件に対応する認証設計のポイントと開発上の工夫を紹介します。
要件定義フェーズで求められたこと：複雑な業務権限と連携制御
本プロジェクトでは、以下のような高度な要件が提示されました：
- アクセス元IPアドレスによる認証スキップ判定
- 顧客企業ごとに異なるSAML連携の要望（Azure AD, Google Workspace 等）
- 役職階層による多段階承認を行うための一時トークン制御
- 社内ツールとのSSO連携、及びログイン履歴の外部API送信
- ユーザーごとに異なるログイン経路とアクセス端末の制御
- 特定ロールのみが利用できるAPIのトークン発行制限
このように、単なるログイン認証にとどまらず、「利用者属性 × アクセス元環境 × 外部連携先」を考慮したフローのカスタマイズが求められました。要件の粒度は非常に細かく、業務上の制約とセキュリティ要件をどこで折り合わせるかという調整力が問われました。
実装アプローチ：三段階構成の認証ゲートウェイ設計
最終的に設計された認証フローは、以下の三段構成を基本としています。
1. 環境トリガーによるパススルー認証
- 特定IP／VPN経由のアクセスは、ID・パスワード入力をスキップ
- 社内イントラからのアクセス時には端末証明書による認証へ切り替え
- プロキシ／ゲートウェイによる環境識別で、ログインフローを短縮化
- アクセス環境をもとにログレベルや認証強度を自動変更
2. 外部IdPとの連携切り替え（SAML/OIDC）
- テナントごとにIdPを選択可能とする動的フロー
- 初回ログイン時にメタデータをキャッシュし、次回以降は自動判定
- ログイン失敗時の再認証ガイド表示やIdP選択画面もカスタマイズ
- SSOを通じた外部サービス連携を想定し、セッション維持処理を追加
3. 内部ロールとアクションごとの認可処理
- APIリクエスト時に機能単位でロール認可チェックを実行
- 承認フローにおいては一時的なJWTトークンで権限委譲
- トークンは用途別にスコープ制御し、再利用を防止
- 操作ログに誰がどのスコープでアクセスしたかを記録
この設計により、「認証と認可を分離しつつ、ユーザー体験を阻害しない」ことが可能になりました。トランザクションの途中で再認証を要求するケースでは、別途モーダルでパスワード入力を求め、操作の中断を最小限に抑える工夫も施されています。
運用設計とセキュリティ要件の両立
柔軟な認証フローの裏には、「運用フェーズでの安全性担保」が必須です。本案件では、以下のような対策が併せて実装されました：
- 管理者UIでのフロー定義変更を履歴管理
- フラグベースで個別機能の有効／無効を切り替え可能に
- 失敗ログイン／不正アクセス試行は即座にSlack通知
- 社内セキュリティチーム向けに毎日のアクセスレポート自動生成
- 社外からのログインであっても、業務端末以外ではフル機能にアクセスできないよう制御
また、全認証イベントをBigQueryへストリーム送信し、後続の監査・分析基盤と接続できるように設計しています。これにより、セキュリティ担当者が自主的にインシデント兆候を検知できる仕組みを整えました。
開発上の学び：開発チーム側に求められる「認証モデル」の理解
今回の案件を通じて、認証にまつわる技術的理解だけでなく、顧客側の業務モデルや組織構造を把握することの重要性を再確認しました。
たとえば、ある企業では「部長以上しかアクセスできない画面」が存在し、かつ「部長認定は定期的に変わる」という前提がありました。このような場合、単純なロール設計では対応できず、ユーザーDBに属性を付与し、別途ロジックで評価する必要が生じます。
さらに、業務委託やグループ企業のメンバーも利用する前提では、「ユーザータイプによるログイン条件の差異」や「時間帯・場所による利用制限」などの柔軟な制御も求められます。こうした複雑性をシンプルな仕組みに落とし込む技術的想像力と業務理解が、受託開発側には欠かせません。
まとめ：認証は“UX”の一部として設計せよ
かつては「固く守る」ことが第一とされていた認証も、今や「使いやすさ」と「柔軟性」の中に組み込まれるべき設計項目となりました。
BtoB向けの受託開発では、セキュリティ担当・業務部門・情シス部門など、関係者の視点が多様であるがゆえに、柔軟で設計可能性の高い「認証フロー」が選ばれる傾向があります。
その中で、「何をどこまで自動化し、何を明示的に管理者に委ねるか」という設計判断が、サービス全体の評価を左右するのです。
今後ますます、認証は「ログイン機能」ではなく「運用インタフェース」としての再定義が進むでしょう。私たち開発者は、その認証UXを支える骨組みを、戦略的かつ持続可能な形で設計していく責務があるのです。
