「ログインはできるのに、この操作だけ弾かれる」という問い合わせを受けたとき、ログイン処理そのものは正しく動いていることがほとんどです。原因は別のところにあります。
認証と認可は、英語にすると Authentication と Authorization で綴りも似ています。日本語でも語感が近く、現場の会話では「認証まわりの不具合」として一括りにされがちです。ですが、この2つが指している作業はまったく別物です。
認証は「あなたは誰か」を確かめること。認可は「あなたに何を許すか」を決めること。
この境界を意識できるようになると、権限まわりのバグを追うときの見当違いが減ります。建物の受付にたとえながら、順番に見ていきます。
認証は「受付の本人確認」——まずここを通らないと始まらない
認証を一言でたとえるなら、建物の受付での本人確認です。
- 来訪者が名前を口で言っただけでは通さない
- 身分証や予約情報を見せてもらい、名乗った本人だと突き合わせる
- 一致して初めて、建物の中へ通す
Webサービスでの流れも同じです。
- メールアドレスとパスワードを入力する
- サービスによっては、スマホに届くワンタイムコードや指紋認証を追加で求める
- 一致すれば「ログイン済み」の状態になる
ここでわかるのは「誰が来たか」だけです。奥のどの部屋に入れるか、何を持ち出せるかは、認証の範囲に含まれません。
認証が済んでも、まだ何もできない
受付を通っただけの来訪者は、実はまだどの部屋にも入れません。名前が確認できただけで、行き先までは決まっていないからです。
ログインに成功しただけのユーザーも同じ状態です。管理画面を開けるのか、他人のデータを見られるのか、その線引きはまだ決まっていません。それを決めるのが認可です。
認可は「入館証」——入ってよい部屋を決める
認可を一言でたとえるなら、本人確認が終わった人に渡される入館証です。
- 入館証には、入ってよい部屋の範囲が印字されている
- 一般来訪者は会議室までだが、社員証を持つ人は執務室の奥まで入れる
- 同じ建物に足を踏み入れていても、証明書の種類で行ける場所が変わる
Webサービスでは、これは「ロール」や「権限」という形で現れます。
- 一般ユーザーは自分の投稿だけ編集できる
- 管理者は全ユーザーの投稿を編集できる
- 無料プランは一部機能に触れず、有料プランは全機能に触れる
認可が決めるのは「どこまでしてよいか」であって、「誰なのか」ではありません。すでに認証で本人だとわかっている前提の上に、権限の範囲を重ねます。
認証を固めても、認可の設計が甘いと崩れる
パスワードを何重にしても、入館証の範囲設定を間違えれば、一般ユーザーが管理者用の画面を開けてしまいます。ログイン自体は正しく機能しているのに、権限チェックの抜けでよそのユーザーのデータが見えてしまう、という報告は実際に少なくありません。認証を固める作業と、認可を正しく設計する作業は別物です。
比較表
| 観点 | 認証(Authentication) | 認可(Authorization) |
|---|---|---|
| 確かめること | あなたは誰か | あなたに何を許すか |
| 実行の順序 | 先に行う | 認証のあとに行う |
| たとえ | 受付の本人確認 | 入館証の発行 |
| 失敗時のふるまい | ログイン画面に戻す(401) | 操作や画面を拒否する(403) |
| 関わる仕組み | パスワード、二段階認証、パスキー | ロール、権限、スコープ |
OAuthとトークンは、どちら側の道具か
OAuthは名前に反して、認証そのものの仕組みではありません。ホテルのカードキーのように「このアプリに、この範囲だけ操作してよい」という許可を発行する仕組みで、実質は認可の一種です。「Googleでログイン」ボタンの裏側でも、Google側での認証が終わったあとに、アプリへの認可(アクセストークンの発行)が行われています。
トークンは、認証・認可どちらの結果も運べる入場リストバンドのようなものです。ログイン済みという証明を運ぶこともあれば、「この範囲まで操作可」というスコープ情報を一緒に運ぶこともあります。トークンを持っているからといって安全とは限りません。中に何の許可が書かれているかまで確認する必要があります。
どう使い分けるか
自前のサービスを作るなら、ログイン処理(認証)と権限チェック(認可)は、コードの上でもはっきり分けて実装してください。同じミドルウェアで済ませようとすると、認可の抜けに気づきにくくなります。
外部サービスと連携する場面では、OAuthの導入を検討してよいです。パスワードを預からずに、必要な範囲だけ操作を許可できるからです。ただし、OAuthを組み込めば認証も済んだと思い込むのは避けてください。認証まで必要なら、OpenID Connectなど別の仕組みを組み合わせます。
迷ったときの目安はひとつです。「この人は誰か」で悩んでいるなら認証の設計を見直し、「この人に何をさせてよいか」で悩んでいるなら認可の設計を見直します。両方を一つの機能だと思って作ると、たいてい権限まわりの事故につながります。
次に「ログインはできるのに、この操作だけ弾かれる」という報告を受けたら、疑うべきは認証ではなく認可の設定です。