一般的な認証機能の選び方
ログイン機能は、作ること自体は難しくない。難しいのは作り続けることだ。パスワードの保存方式、多要素認証、ソーシャルログインの仕様変更、不正ログインの検知——脅威と標準は変化し続け、追随を止めた瞬間に穴になる。
自前で持つべきか
認証が事業の差別化要因になることはほぼ無い。それでいて実装を誤ったときの被害は最大級になる。特殊な要件（既存の社内認証基盤との統合、外部にユーザー情報を置けない制約）が無い限り、外部サービスに寄せるのが合理的だ。
外部サービスを入れても検証の責任は自社に残ります
発行されたトークンをどこに保管し、サーバー側でどう検証するかは自社の実装です。トークンをローカルストレージに置けば XSS で盗まれますし、署名・有効期限・発行者・対象者の検証を書いていなければ、トークンを持っているだけで通ってしまいます。導入したこと自体が安全性を保証するわけではありません。
想定する利用者で要件が変わる
- 一般消費者向け — ソーシャルログインの有無が登録率に効く。パスワードレスの選択肢も
- 法人向け（B2B） — 組織単位の管理、SSO（SAML / OIDC）への対応が要求される
- 社内利用 — 既存の ID 基盤との連携が前提になることが多い
B2B では、導入先企業から SSO 対応を求められた時点で対応できるかが受注条件になることがある。将来の要件として頭に入れておきたい。
標準に寄せておく
OpenID Connect と OAuth 2.0 の標準的な範囲で実装しておけば、サービスを乗り換えるときの改修が小さく済む。逆に、特定サービスの独自拡張に深く依存すると、料金改定や方針変更があっても動けなくなる。導入時に意識しておくと後の選択肢が残る。