認証・認可・ログイン状態

認証と認可

セキュリティの話題では「認証」と「認可」という2つの言葉が出てくることがあります。この2つは名前こそ似ていますが、別物です。混同しやすいので注意しておきましょう。

認証（Authentication / AuthN）

認証とは 「あなたが誰であるか」 を判断する仕組みです。例えば、ID とパスワードを入力する、二段階認証のパスコードを入力する、パスキーでデバイス認証をする、といった行為はすべて「認証」にあたります。

より固く言えば、認証とはユーザーの身元など（identity）の主張（identification）を検証する（authentication）プロセスと表現できます。

認証情報、という言葉も良く使われますが、これは「あなたが誰であるか」を示してくれる情報のことです。ID とパスワードの組み合わせや生体情報（指紋や顔など）がこれにあたります。

認可（Authorization / AuthZ）

認可とは 「あなたが何をしてよいか」 を判断する仕組みです。ユーザーが認証されていること（＝この人だと識別されていること）と、そのユーザーが特定の情報を閲覧してよいか／特定の操作を実行してよいかは全くの別物で、後者は「認可」の問題です。

こう聞くと、認可を行うためには認証によってまず「そのユーザーが誰であるか」を知っていることが前提になっているように感じられるかもしれませんが、純粋な「認可」とは「特定の条件にしたがって、特定のアクセス権限を与えること」であり、ユーザーの特定という考え方は含んでいません。

認証と認可を分離する

とは言いつつも、昔から認証と認可は不可分なものとして扱われることが多くありました。

• ユーザーは A さんだから、この操作を許可する
• ユーザーは B さんだから、この操作は許可しない
• ユーザーが判断できないから、この操作は許可しない

のように、認証の結果に基づいて認可が行われるような場合ですね。

前述の通り、純粋な「認可」の概念自体は「条件に基づいてアクセス権限を与えること」であり、ユーザーが「誰」といったこととは関係ないのですが、その条件が「ユーザーがこの人であること」になっていることが多いので、認証と認可はまとめて扱われがちです。

ここでは、このまとめられがちな認証と認可を分離するために、それぞれについて少し時間を取って考えてみましょう。認証と認可の分離は、この後に紹介する技術を理解するうえでも重要になります。

認証と認可（再）

認証とは、通信しているあなたが誰であるかを判断することでした。純粋な認証はそれが完了したからと言って何かが許可される話とは関係ありません。

例えば、あなたが身分証明書を持って「私はAです」と主張したとしましょう。それを見た周りの人はあなたがAであることを信じると思います。でも、Aなんだね、それだけです。

認可とは、特定の条件に基づいてアクセス権限を与えることでした。純粋な認可は、それがあるからといって身元が明らかになる話とは関係ありません。

友達から紙のクーポン券をもらいました。クーポン券を持っているのであなたは割引価格で商品を買うことができます。あなたが誰であるかはこの際考慮されていません。

認証と認可の分離の好例

認証せずに認可する

上のクーポン券の例がそれですね。あなたは持っているものによって身分を明かさずとも特定の権限を得ることができました。

特定のIPアドレスからのリクエストを許可したり、特定のブラウザ情報（ユーザーエージェント・UA）のリクエストを許可したり、こういうのも認証に基づかない認可です。

認証したのに認可しない

このケースは原則存在しません。ただし、複数のシステムが連携して一つのサービスを作っているような特別な環境では、認証を行うシステムとそれに基づいて認可を行うシステムが分かれていることがあります。

このような場合、全体で見れば認証に基づく認可という一般的なことをしていても、ミクロな視点では認証だけして認可はしていないという状況が成立し得ます。

ログイン状態

ここまで、認証と認可の違いについて説明してきました。ここで少し脇道にそれて、「認証状態の維持」について考えてみましょう。認可の話は一旦置いておきます、ここでは関係ありません。

ウェブ上での「認証」は多くの場合、ID とパスワードの組み合わせによって行われます。有効な ID とパスワードを持っていることによって、リクエストの通信元があなたであることを相手は認識します。これがログインです。

ただし、この認証はあくまでも今回のリクエストに対して、通信元があなたであることを示しただけです。別のリクエストを飛ばすとき、新しいページを開いたときにはまた認証しなくてはなりません。こうなると、あなたは何度も何度も ID とパスワードを入力しなくてはならず、これはあまりに不便ですね。

そこで登場するのが「セッション」という概念です。毎回 ID とパスワードを打たせる代わりに、ユーザーに対して「セッション」を発行し、セッションが有効な間は手動での認証をスキップする仕組みです。

では、セッションは具体的にどのように発行されるのでしょうか。ここでは、良く使われる手法として「Session ID を使った方法」と「JWT を使った方法」を紹介します。

Session ID を使った方法（Session Based Authentication）

Session ID を使った方法は、古くから広く利用されているセッション管理方法です。

一度認証が成功すると、サーバーはランダムで十分に推測困難な文字列 Session ID を生成し、ユーザー（ブラウザ）に渡します。

その後、ユーザーがページを移動したりその他のリクエストを行ったりするたびに、ブラウザは Session ID を自動的に送信します。サーバーは受け取った Session ID をもとに保存しておいてセッションの情報を参照し、この Session ID に紐づいているユーザー情報を確認することで、このユーザーはあなたであると判断します。

この方式の特徴は、Session ID 自体は意味を持たないランダムな文字列であり、実際の認証状態・ユーザー情報はサーバーが保存している点にあります。

例えば、以下のようなセッションのテーブルをサーバーが保持しています。

Session ID	User	Expires At
abc123	Aさん	2026/06/30
xyz789	Bさん	2026/06/30

JWT を使った方法（Token Based Authentication）

JWT (JSON Web Token, 「ジョット」と発音します) は、認証状態をサーバーではなく発行したトークンに持たせる方式です。

認証に成功すると、サーバーは JWT と呼ばれる特定の形式のテキストデータを発行します。例えば、JWT は以下のような形式です。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsInN1YiI6IjEyMzQ1IiwibmFtZSI6IkHjgZXjgpMiLCJyb2xlIjoibWVtYmVyIiwiZXhwIjoxNzgwMDAwMDAwfQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.hiJ9aUT56609Xago_y30fYYHiY9hKntcpPW9Og7BIs0

JWT はルールに基づいてデコード（復号）すると、JSON に変換できます。上の JWT はデコードすると以下の JSON が得られます。

{
  "alg": "HS256",
  "typ": "JWT",
  "sub": "12345",
  "name": "Aさん",
  "role": "member",
  "exp": 1780000000
}

Session ID 方式と同様に、JWT もブラウザが記憶し、次回のリクエスト時やページ遷移時に自動的に送信します。サーバーはこの JWT の中身（デコードした結果）を読むことで、あなたが誰であるかを判断します。

一方、Session ID と異なるのは、根本的にサーバーがあなたが誰であるかを信じるための情報がサーバーではなくリクエスト元にある点です。単純に考えると、悪意のあるユーザーが勝手に JWT を書き換えるだけでサーバーに自分の身分を偽ることができてしまいますが、JWT には改ざん検知用の電子署名が含まれており、内容が変更されると検証に失敗するため、不正なトークンとして拒否されます。

Cookie

Session ID も JWT も「ブラウザが記憶し自動的に送信する」という説明をしてきましたが、この仕組みの実現には「Cookie（クッキー）」という技術が使われています。

Cookie の仕組みや仕様についてはここでは割愛しますが、Cookie を使うことで小さなデータをブラウザに記憶させ、自動的に次回のリクエストで送信させられる、ということを押さえておきましょう。