「認証」と「認可」、漢字も読み方も似ていて混同しやすい——そんな声をよく聞きます。実はこの2つ、IT資格の学習でもWebシステムの設計でも頻出のキーワードで、役割の違いを押さえておくとセキュリティの理解が一気に整理されます。
この記事では、オフィスビルの入館ゲートのたとえを使いながら、専門用語をなるべく使わずに解説します。IT資格の学習中の方や、Webシステムの仕組みを初めて学ぶ方に向けた内容です。
まず結論：認証と認可は「確認する対象」が違う
細かい説明の前に、一言でまとめます。
- 認証（Authentication）：「あなたは誰か」を確認すること
- 認可（Authorization）：「あなたに何を許可するか」を確認すること
- 認証をパスした人でも、認可がなければアクセスできない領域がある
この2つは順番も役割も別物です。以下で順番に説明します。
認証とは？――受付での本人確認のようなもの
認証とは、「その人が本人であること」を確認する仕組みです。
オフィスビルの受付を思い浮かべてください。入館するとき、社員証を機械にかざしたり、顔認証カメラの前に立ったりします。これは「この人は本当に社員のAさんなのか」を確認する行為です。
Webシステムでも同じで、以下のような手段で本人確認を行います。
- ID・パスワードの入力
- SMSやアプリによる2段階認証（多要素認証）
- 生体認証（指紋・顔）
身近なたとえだと、こうした確認に近いです。
- 病院の受付での保険証確認
- 空港での搭乗券とパスポートの照合
- 宅配便の受け取り時の本人確認
つまり、「誰であるか」だけを確認する作業です。認証が通った時点では、まだ「何をしていいか」は決まっていません。
認可とは？――ICカードで開くフロアが決まる仕組み
認可とは、「本人確認が済んだ人に、何を許可するか」を決める仕組みです。
先ほどのオフィスビルの続きで考えると、受付を通過したAさんが持っているICカードは、すべてのフロアの扉を開けられるわけではありません。
- 一般社員のAさんは3階・4階のフロアだけ開けられる
- 人事部のBさんは5階の人事フロアも開けられる
- 役員のCさんは役員フロアも開けられる
同じ「本人確認済み」の状態でも、開けられる扉は人によって違います。これが認可です。
Webシステムでは、認可は主に以下のような形で実装されます。
- 一般ユーザーと管理者で見える画面を分ける
- 自分のデータだけ編集できて、他人のデータは編集できないようにする
- 有料会員だけが特定のコンテンツを閲覧できるようにする
「認証と認可の違い」を入館ゲートでたとえると
認証 ＝ 受付での本人確認
- 「あなたは誰ですか」を確認するプロセス
- パスした・しないの二択（本人か、本人でないか）
- 一度確認できればビルには入れる
認可 ＝ ICカードで開くフロアの範囲
- 「あなたはどこまで入れますか」を決めるプロセス
- 人によって許可される範囲が違う
- ビルに入れても、開かない扉がある
| 項目 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| 確認すること | あなたは誰か | あなたに何を許可するか |
| タイミング | 最初に1回行う | 各操作・各画面ごとに判定する |
| 失敗時のHTTPステータス | 401 Unauthorized | 403 Forbidden |
| 代表的な仕組み | パスワード・多要素認証（MFA） | 権限管理（RBAC）・アクセス制御リスト（ACL） |
| 略した呼び方 | AuthN | AuthZ |
なぜ認証だけではダメなのか？
「本人であることが確認できたなら、あとは全部見せてもいいのでは？」と思うかもしれません。しかしこれには大きなリスクがあります。
たとえば、社員なら誰でもログインさえできれば、他部署の給与データや人事評価まで見られてしまうシステムがあったとします。これは本人確認（認証）はできていても、権限管理（認可）が欠けている状態です。
このように認証は通っているのに認可のチェックが不十分で、本来アクセスできないはずの情報や機能に触れてしまう不具合は「Broken Access Control（アクセス制御の不備）」と呼ばれ、OWASPが公開している代表的なWebアプリケーションのリスク一覧「OWASP Top 10」でも上位に位置づけられる深刻な脆弱性です。詳しくはOWASPのAuthorization Cheat Sheetでも解説されています。
認証と認可を分けて設計し、「本人であること」と「何をしてよいか」を別々にチェックすることが、安全なシステムには欠かせません。
実際の使われ方：ログインから画面表示までのステップ
社内の勤怠管理システムを例に、認証と認可がどう連携して動くか流れを見てみましょう。
Step 1 — ユーザーがID・パスワードを入力してログインする。
Step 2 — システムが入力内容を確認し、「本人である」と判定する（＝認証）。
Step 3 — システムはこのユーザーに紐づく権限情報（一般社員／管理者など）を確認する。
Step 4 — ユーザーが「他部署の勤怠一覧」を開こうとする。
Step 5 — システムは権限情報を照合し、「このユーザーには他部署の閲覧権限がない」と判定する（＝認可）。
Step 6 — アクセスが拒否され、「403 Forbidden」などのエラーが返される。
Step 7 — 一方で「自分の勤怠」を開こうとした場合は、権限があるため正常に表示される。
このように、認証は入り口で1回、認可は操作のたびに繰り返しチェックされる点が大きな違いです。
まとめ：3行で理解する認証と認可
- 認証 = 「あなたは誰か」を確認するプロセス（受付の本人確認）
- 認可 = 「あなたに何を許可するか」を確認するプロセス（ICカードで開くフロアの範囲）
- 両方が揃って初めて安全 = 認証だけでは不十分で、認可のチェックがなければ権限のない情報にアクセスされてしまう
認証と認可を別の仕組みとして捉えられるようになると、Webシステムのセキュリティ設計の理解がぐっと深まります。IT資格の学習でも頻出のポイントなので、ぜひ押さえておいてください。
よくある質問
Q. 認証と認可、英語で言うとどう違いますか？
A. 認証は Authentication（略して AuthN）、認可は Authorization（略して AuthZ）です。スペルが似ているため、実務でも意識的に略語を使い分けることが多いです。
Q. ログインさえできれば認可も自動的に通るのですか？
A. いいえ、別物です。ログイン（認証）が成功しても、特定の機能やデータにアクセスする際には、そのつど権限（認可）が確認されます。認証が通った直後でも、権限がない操作は拒否されます。
Q. 401と403、どちらも「アクセスできない」というエラーですが違いは何ですか？
A. 401 Unauthorized は「本人確認ができていない」状態を示すエラーで、多くはログインが必要であることを意味します。403 Forbidden は「本人確認はできているが、その操作を行う権限がない」状態を示すエラーです。名前からは紛らわしいですが、401は認証、403は認可に対応しています。
Q. IT資格の試験では認証と認可はどのように出題されますか？
A. 基本情報技術者試験や応用情報技術者試験のセキュリティ分野では、「本人確認の仕組み」と「アクセス権限の仕組み」を区別する問題として出題されることがあります。用語の意味だけでなく、具体的な仕組み（パスワード認証、多要素認証、権限管理モデルなど）とセットで理解しておくと得点につながりやすいです。
コメント