ユーザー認証（独自実装する場合）

3-1. 認証方式の選定

採用する認証方式とその理由を定義する。方式によって実装コスト・セキュリティリスク・運用負荷が大きく異なるため、早期に意思決定する必要がある。

⚠️ 定義しないと…

実装者がそれぞれの判断で作り始め、後から統一できなくなる。パスワードログインで作り始めた後に「Googleログインも欲しい」となると、認証基盤の大幅な改修が必要になる。

パスワードは必ずハッシュ化（bcrypt / Argon2等）して保存する。平文保存を禁止することを憲章で明示する。

⚠️ 定義しないと…

実装者が「とりあえず動けば」とパスワードを平文でDBに保存するケースがある。情報漏洩が発生した場合、全ユーザーのパスワードが流出し、法的責任・サービス廃止レベルの問題に発展する。

セッションの有効期限、リフレッシュ方式、ログアウト時の無効化方法を定義する。

項目	定義すべき内容
有効期限	例：アクセストークン15分、リフレッシュトークン30日
更新方式	自動リフレッシュか、再ログインか
無効化	ログアウト時・パスワード変更時にセッションを即時破棄するか

⚠️ 定義しないと…

有効期限のないトークンが発行され、一度ログインしたユーザーが永久にアクセスできる状態になる。端末紛失・アカウント不正利用が発生してもセッションを止める手段がなくなる。

メールアドレス、行動ログ、IPアドレス等のうち、何を「個人情報」として扱うかを決める。

⚠️ 定義しないと…

個人情報保護法・GDPRの義務対象が不明確なまま開発が進む。リリース後に「これは個人情報だったのか」と気づき、プライバシーポリシーの作り直しや機能の大幅改修が必要になる。

ユーザーが退会した際にデータを即時削除するか、一定期間保持するかを定義する。

⚠️ 定義しないと…

「退会したのに自分のデータが残っているのでは？」という問い合わせに答えられない。GDPRでは「削除権（忘れられる権利）」が法的に保障されており、対応していない場合は法令違反になりうる。

ロール（管理者・一般ユーザー等）と、誰が誰のデータにアクセスできるかのルールを定義する。

⚠️ 定義しないと…

一般ユーザーが他のユーザーのデータを参照・編集できる実装ミスが発生する。管理者権限の範囲も曖昧になり、内部不正のリスクも高まる。

N回連続で認証に失敗したらアカウントをロック、または一定時間のウェイトを設ける。

⚠️ 定義しないと…

ブルートフォース攻撃（パスワードを総当たりで試す攻撃）に対して無防備になる。自動化ツールで数千回のログイン試行が繰り返され、アカウントを乗っ取られる。

✅ 実装の目安

一般的には5〜10回の失敗でアカウントロックまたはCAPTCHA要求。ロック解除はメールによるリセットか、一定時間経過後の自動解除が一般的。

プロジェクトの特性に応じた認証方式の選択基準をまとめる。複数を組み合わせることも多い。

認証方式	向いているケース	注意点
メール＋パスワード	独自ユーザーDB管理が必須、外部依存を避けたい	パスワードリセット・ハッシュ化・ブルートフォース対策を全部自前で実装
ソーシャルログイン（OAuth2/OIDC）	BtoCサービス、UX優先、実装コストを下げたい	プロバイダ障害時にログイン不能になる。アカウント連携の設計が必要
マジックリンク	パスワードレスを優先、メアドが確実に確認済み	メール到達性に依存。URLの有効期限管理が必要
SAML / OIDC SSO	BtoBで顧客企業のIdPと連携、社内システム	IdP側の設定が必要。実装・テストコストが高い
MFA（TOTP/SMS）	金融・医療・高セキュリティ要件	ユーザーの離脱率増加に注意。MFAの強制 or 任意を明確に

✅ Cognitoや Auth0 などのIdaaSを検討する

独自実装は認証基盤の全責任を自前で持つことを意味する。開発コスト・セキュリティ保証・MFA対応を考慮すると、Amazon Cognito・Auth0・Firebase Authenticationなどのマネージドサービスの採用が合理的なケースも多い。「なぜ自前実装か」を憲章に記載しておくこと。