2つの問いを分ける

ログインまわりの設計は、次の2つの問いに分けて考えます。

講座31の第3回では、認可の書き忘れ（URLのIDを書き換えると他人のデータが見える）を見ました。この講座では一歩手前に戻って、最初にどう決めておくと、後から困らないかを扱います。

入ってくる「主体」を先に数える

「ログインする人」は1種類とは限りません。まず、システムに入ってくる主体（だれが・何が）を数えます。naminori なら、次のようになります。

naminori では、会員と管理者をログインの仕組みごと分けています。会員としてログインしても、管理画面には入れません。さらに、管理者だけは一定時間操作が無いと自動でログアウトし、会員はログインしたままにできます。

後から困ること①「ログインしていれば全部できる」

最初は利用者が1種類なので、「ログインしているか」だけ確かめて作りがちです。

半年後、「企業の担当者にも画面を開けたい」「閲覧だけのスタッフを入れたい」と言われます。ところが、どの画面が誰向けなのか、コードのどこにも書かれていません。結局、全画面を1つずつ読み直して判定を足すことになります。読み漏らした画面は、誰でも使える穴として残ります。

後から困ること② 管理者を「会員の1人」にする

会員の表に「管理者かどうか」の印を1つ足すだけなら、すぐ作れます。でも、会員向けの仕組み（ログインしたままにする、パスワードを再設定する、外部サービスでログインする）が、そのまま管理者にも効いてしまいます。

「管理者だけ短い時間で自動ログアウトさせたい」「管理者だけ多要素認証を必須にしたい」と思ったときに、会員と切り分けられません。強さを変えたい主体は、最初から分けておきます。

最初に書いておく表

設計の最初に、「主体 × 入口 × できること」の表を1枚書きます。入口とは、ログイン画面・API・外部アプリの接続など、主体が入ってくる経路のことです。この表があれば、主体や入口が増えたときに、どこを直せばよいかが分かります。

• 認証と認可の違い
• 入ってくる主体を数える（naminori の例）
• 「ログイン済みなら全部OK」で作ると後から困ること
• 管理者を会員の1人にすると後から困ること