誰が何をできるか

本人確認と操作の許可は別

席の予約サービスで予約を取り消すときは、誰が操作しているかと、その人に取り消しを許すかを確かめます。前者が認証、後者が認可です。

DAU 3万人が1人6回アクセスするサービスでも、この区別は変わりません。利用者が増えても、取り消しの要求ごとに対象の予約との関係を確認します。

済んでいるのは本人確認です。ログインした利用者でも、他人の予約IDを指定して取り消そうとすることがあります。

ボタンを本人の画面だけに表示しても、APIへ直接要求を送ることはできます。取り消しを実行するAPIで、保存された予約の所有者と操作する本人を比べます。

信じてよい情報の順に判断する

本人確認は、サーバーが検証したログイン情報から行います。要求に書かれた利用者IDや「管理者」という役割を、そのまま本人の情報として使いません。

要求の役割を信じると、未ログインの相手も管理者を名乗れます。先に本人を確かめ、その人の役割をサーバー側の信頼できる情報から取得します。

このサービスでは、管理者か予約の所有者なら取り消しを許し、それ以外は断ります。判定の順番は、信じてよい情報を先にそろえるためにあります。

操作ごとに許可の範囲も決めます。予約を見られることから取り消せると推測せず、誰がどの操作をできるかを要件として残します。

断る理由と外への説明を分ける

本人確認が済んでいないなら、呼ぶ側はログインを案内できます。他人の予約なら、同じ本人でログインし直しても取り消しは許されません。

予約IDを総当たりする相手に「他人の予約」と返すと、そのIDが実在すると教える場合があります。存在しない場合と権限がない場合は、外には同じ文言を返す設計にできます。

内部のログには、調査に必要な範囲で区別した理由を残します。ログの閲覧権限も絞り、予約の内容やログイン情報を丸ごと書かないようにします。

予約サービスで解いてみる

予約7002の所有者は利用者71です。本人確認済みの利用者82が、要求に「役割は管理者」と書いて、この予約の取り消しを送ってきたとします。

サーバー側で調べた利用者82の役割は一般利用者でした。要求の役割を採用せず、次の順で判断します。

結論は取り消し不可です。内部には権限不足を記録し、外には予約の存在を明かさない「この予約は操作できません」という文言を返します。

本人確認済みの管理者なら、このサービスの要件に従って許可します。許可する根拠は相手の自己申告ではなく、確認した本人の役割と予約の所有者です。