認証基盤を選ぶときの判断軸
認証は「作れるが、作り続けるのが重い」機能の代表だ。パスワードのハッシュ化、MFA、ソーシャルログイン、パスワードリセット、不正ログイン対策——一度作って終わりではなく、脅威の変化に追随し続ける必要がある。外部サービスを使う理由の大半はここにある。
自前と外部委託の分かれ目
- 外部に寄せる — 認証が事業の差別化要因でない場合。ほぼすべてのケースが該当する
- 自前で持つ — 特殊な認証要件がある、外部にユーザー情報を置けない、といった制約がある場合
発行されたトークンをどこに保管し、サーバー側でどう検証するかは自社の実装です。アクセストークンをローカルストレージに置けば XSS で盗まれますし、署名・有効期限・発行者・対象者の検証を書いていなければ、トークンを持っているだけで通ってしまいます。「入れたから安全」ではありません。
ID トークンとアクセストークンの取り違え
OpenID Connect では、ID トークン(誰がログインしたか)とアクセストークン(API を呼ぶ権限)は役割が異なる。ID トークンを API の認可に使う実装は誤りで、想定しない相手を通す危険がある。設計の初期に役割を明確にしておきたい。
コストカーブと移行しやすさ
多くのサービスが月間アクティブユーザー数で課金するため、ユーザーが伸びた段階でコストが跳ねる。そのときに移行できるかどうかは、標準仕様(OpenID Connect / OAuth 2.0)にどれだけ寄せているかで決まる。独自拡張に深く依存すると、料金改定があっても動けなくなる。