ログインの方式を 1 つに絞った回です。選んだ理由と、同意をどこで取るかを決めました。
やったこと（3 ステップ）
- 認証の方式を 3 つ比べて、Google だけにする
- 入口を「Google で続ける」1 つにして、ログインと新規登録を分けない
- 未登録なら同意画面へ送り、2 つのチェックを得てからアカウントを作る
判断：パスワードを持たない
3 つ比べました。
| 候補 | 却下・採用の理由 |
|---|---|
| メール＋パスワード | 自分で保管する＝漏れる対象を自分で作る。再設定メール・強度のルール・連続失敗のロックも要る。1 人・1 か月半では作りきれない |
| X・Facebook・LINE | 調べた時点では、どれも開発者登録や審査が要った。Google は同意画面の設定だけで、メールとプロフィールの範囲なら審査なしで始められた |
| 採用。 旅行の記録を残す層なら、ほぼ全員が持っている |
決め手は「漏れる対象を作らない」でした。要件定義書の非機能要件にも「パスワードは一切保持しない」と書いて、あとから揺れないようにしました。
判断：入口は 1 つだけにする
ログインボタンと新規登録ボタンを分けませんでした。
外部の認証は、通ったかどうかしか教えてくれません。「この人が登録済みか」は分からないのです。2 つのボタンを置くと、利用者が選んだ側と実態が食い違い、「新規登録を押したのに既にあると言われる」が起きます。
入口を 1 つにして、通ったあとにこちらで調べて分岐することにしました。Google のアカウント選択も 1 回だけです。
工夫：「認証済みだが未登録」という状態を作る
同意をもらう前にアカウントを作りたくない。でも認証状態を捨てると、アカウントを選び直させることになる。
そこで中間の状態を作りました。認証は保持したまま、同意画面と認証まわりの API 以外には行けないようにします（それ以外の画面は同意画面へ戻し、API は 401）。同意せずに離れたら、認証状態は捨てます。
同意の確認は画面とサーバーの両方でやります。画面のチェックだけだと、API を直接呼ばれたときに素通りします。
気をつけたこと：規約だけは、ログインしていなくても読める
同意画面から利用規約のリンクを踏んだら、規約が読めずにログイン画面へ飛ばされました。
原因は共通のメニューバーでした。バーが未読通知の件数を取りに行き、同意前の人には 401 が返り、その扱いでログイン画面へ送られていたのです。
規約と個人情報保護方針は「バーを出さない画面」に加えて直しました。同意を求める相手に、同意する対象を読ませないのは筋が通りません。
決めた決まり
- パスワードは保持しない。 保管しないものは漏れない
- 同意は画面とサーバーの両方で確かめる。 画面の制御は、API を直接呼ばれたら効かない
- 規約と個人情報保護方針は、ログインしていなくても読める。
次回
Vercel のサーバーレスで諦めたこと 3 つ。