はじめに

個人アプリに「ログイン機能」を実装しようとするとき、最近はSupabase AuthやAuth.js（NextAuth）などの便利なツールがあるため、数行のコードで簡単に画面が作れてしまいます。

しかし、裏側の仕組みをブラックボックスのままにしておくと、重大なセキュリティの穴（脆弱性）を自ら作り込んでしまう危険があります。

ログインの裏側を紐解く第一歩は、なんとなく一括りにしがちな「認証」と「認可」という、似ているようで全く異なる2つの仕組みを正しく区別することです。

今回は、この2つの本質的な違いから、実際にブラウザとサーバーの間でどんなデータが飛び交っているのかまで、図解を交えて丁寧に整理していきます。

1. 認証とは何か

認証（Authentication）とは、「あなたは誰ですか」を確認する仕組みのことです。

英語の頭文字を取って、AuthNと表記されることもあります。

最も身近な例は、IDとパスワードによるログインです。

データベース（ユーザーテーブル）にあらかじめ登録されている「ハッシュ化されたパスワード」と、ユーザーが画面から入力したパスワードが一致するかを照合し、「このリクエストを送ってきたのは、間違いなくAさん本人だ」と特定するプロセスを指します。

最近では、パスワードの代わりに指紋や顔認証を使う生体認証や、GoogleやGitHubなどの外部アカウントを連携させる「ソーシャルログイン（OAuth / OIDC）」も一般的ですが、これらもすべてアプローチが違うだけで、目的は同じく「本人確認（認証）」です。

2. 認可とは何か

一方で、認可（Authorization）とは、「あなたに何を許可するか」を決める権限チェックの仕組みのことです。

こちらは AuthZ と略されます。

「ログインできた（＝認証完了）」からといって、そのアプリ内のすべてのデータを自由にいじっていいわけではありません。

例えば、社内のシステムを思い浮かべてみてください。

一般社員： ログイン後、自分の勤怠データだけを閲覧・編集できる
人事担当者： 全社員の勤怠データを閲覧・集計・承認できる
システム管理者： ユーザーの追加や削除、システムのマスター設定を変更できる

このように、ユーザーが「本人」だと分かった後に、「そのユーザーの役割（ロール）に応じて、実行しようとしている操作を許可するかどうか」を裏側でジャッジするのが認可の役割です。

3. 認証と認可の違いを具体例で整理する

言葉だけだと混同しやすいので、空港のたとえで整理してみます。

認証： 保安検査場や出国審査で、パスポートと搭乗券を提示し、「あなたが間違いなくこのパスポートの顔写真の人物であること（本人）」を確認してもらうプロセス。
認可： 飛行機の搭乗口で搭乗券のバーコードをかざし、「あなたがこの飛行機の、ファーストクラス（またはエコノミークラス）のエリアに入ってよいか」をシステムが判断するプロセス。

本人確認ができたからといって、どの飛行機にでも自由に乗れるわけではありません。

搭乗券に書かれた便やクラスに応じて、案内される範囲が決まります。

Webアプリケーションにおける2つの違いを一覧表にまとめました。

観点	認証（Authentication）	認可（Authorization）
略称	AuthN	AuthZ
確認する内容	ユーザーは誰か？（本人確認）	ユーザーに何を許可するか？（権限確認）
タイミング	アプリを開いて最初にログインするとき	画面を開く、ボタンを押すなど操作のたび
裏側でのデータ照合	`users` テーブルのパスワード等と照合	`role` フラグや権限テーブルのチェック
失敗した場合	ログイン画面に戻され、エラーが出る	「403 Forbidden（権限がありません）」となる

4. ログインの裏側で起きていること（全体像）

では、実際にユーザーがログインボタンを押してから、マイページが表示されるまでの「裏側のデータの流れ」をシーケンス図で追ってみましょう。

重要なのは、一度ログインした後は、リクエストのたびに毎回パスワードを送り直しているわけではない、という点です。

代わりに「証明書（トークンやセッションID）」を使い回します。

sequenceDiagram
    autonumber
    actor User as ユーザー（ブラウザ）
    participant Server as サーバー（アプリケーション）
    participant DB as データベース

    Note over User, Server: 【ステップ1：認証（本人確認）】
    User->>Server: 1. ID・パスワードを送信
    Server->>DB: 2. ユーザー情報を照会
    DB-->>Server: 3. 一致を確認
    Server-->>User: 4. 「ログイン証明書（セッションID / JWT）」を返却

    Note over User, Server: 【ステップ2：認可（権限チェック）】
    User->>Server: 5. データの削除をリクエスト（＋ログイン証明書を添付）
    Server->>Server: 6. 証明書を検証（誰のリクエストか特定）
    Server->>DB: 7. このユーザーに「削除権限」があるか確認
    DB-->>Server: 8. 権限ありを確認
    Server->>DB: 9. 実際のデータを削除
    Server-->>User: 10. 「削除に成功しました」と画面に表示

💡 補足：2つの「証明書」のスタイル

上記ステップ4でサーバーからブラウザに渡される「ログイン証明書」には、2026年現在、大きく分けて2つの主要な実装パターンがあります。

データ構造の思想が異なるため、個人開発でもどちらを使うかの選定が必要です。

セッション（Stateful）方式：

サーバー側に「ログイン状態」のメモリやテーブルを保持し、ブラウザにはその鍵となるランダムな文字列（セッションID）だけを渡す方式です。

データがサーバー側で管理されるため安全ですが、アクセスが増えるとサーバー側のメモリやDB（Redisなど）の負荷が上がります。
JWT（Stateless）方式：

ユーザーのIDや権限などの情報を、改ざんできない署名付きのJSON（JWT：JSON Web Token）に暗号化し、ブラウザ側に丸ごと持たせる方式です。

サーバー側は「状態（State）」を持つ必要がなく、署名の正しさを判定するだけで済むため、スケールしやすいのが特徴です。

Supabase AuthやFirebase AuthなどのBaaSではこの方式が主流です。

5. 混同しやすいポイント

実装の現場で最も多いセキュリティ事故は、「認証が通っている＝何をしてもよい」と勘違いして、プログラムを書いてしまうケースです。

例えば、自分が作成したデータを編集するURLが [https://myapp.com/posts/123/edit](https://myapp.com/posts/123/edit) だったとします。

ここで、悪意のある別のユーザーがログインした状態で、URLの数値を勝手に変えて [https://myapp.com/posts/456/edit](https://myapp.com/posts/456/edit) に直接アクセス（URL直打ち）したとします。

このとき、システム側のコードが以下のようなロジックになっていたらどうなるでしょうか。

// ❌ 脆弱性のあるコードのイメージ
if (!isLoggedIn) {
  return "ログインしてください"; // 認証チェックだけしている
}

// 誰のデータであるかの確認（認可）をせずに、データを取得して画面に表示してしまう
const post = idからデータを取得(456); 
return post;

このコードでは、「ログインしているか（認証）」はチェックしていますが、「そのデータ（456番）を、今ログインしているユーザーが本当に編集してよいか（認可）」のチェックが抜け落ちています。

結果として、ログインさえしていれば、他人の非公開データをURLの数字を変えるだけで盗み見たり、削除できたりしてしまう重大な脆弱性（IDOR：不適切な直近オブジェクト参照）が生まれます。

「認証（ログイン状態）」のチェックをパスした後に、必ず「今リクエストしてきたこの人に、このデータを触る権限があるか？」という一歩踏み込んだ認可ロジックを書く。

これこそが、安全なアプリを作るための鉄則です。

まとめ

ログイン機能の裏側で動く「認証」と「認可」について整理しました。

認証（AuthN）： 「あなたは誰か」を確かめる、最初のゲート（パスポート提示）。
認可（AuthZ）： 「あなたに何を許可するか」を操作のたびに確かめる、内側のゲート（搭乗券のクラス確認）。
証明書のやり取り： ログイン後は毎回パスワードを送るのではなく、セッションIDやJWTという証明書を使って、リクエストごとに認証と認可を高速に処理している。

ライブラリを使うとこれらは自動的に処理されているように見えますが、API（バックエンドの処理）を自前で実装する際には、必ず「認可のコード（権限確認）」を意識して挟み込む必要があります。