認可とは？認証との違いを最初に整理

最初に: 認可は「ログインできたか」ではなく「何をしてよいか」

認可は、あるユーザーやシステムが どの情報にアクセスできるか どの操作をしてよいか を決める仕組みです。
一方、認証は その人が誰かを確認すること です。

この2つはセットで語られやすいですが、役割は違います。

認証 = 誰かを確認する
認可 = 何をしてよいかを決める

たとえば、社内システムへログインできたとしても、全員が給与情報を見てよいわけではありません。
ここで必要になるのが認可です。

この違いが曖昧だと、

ログイン済みなら何でも見えてしまう
一般ユーザーが管理者用APIを叩けてしまう
他人のデータをURL変更だけで見られてしまう

といった事故につながります。
OWASP でも、認可は認証と別物であり、アクセス制御の不備は重大な脆弱性になりやすいと整理されています。

この記事では、2026年4月24日時点で Microsoft Learn、OWASP Authorization Cheat Sheet、OWASP Authentication Cheat Sheet を確認しながら整理しています。

認可とは何か

短く言うと、認可は 許可の判定 です。

具体的には次のような判断です。

このユーザーはこの記事を編集してよいか
この社員は管理画面へ入ってよいか
このAPIクライアントは書き込みしてよいか
この担当者は請求情報を見てよいか

つまり、ログイン後に本当に大事になるのが認可です。
認証が通っても、認可が弱いと情報漏えいや不正操作を防げません。

認証との違い

ここを最初に固定しておくと、かなり混乱しにくくなります。

項目	認証	認可
目的	誰かを確認する	何をしてよいか決める
代表例	パスワード、MFA、SSO	ロール、権限、ポリシー
判定例	本人かどうか	編集可能か、閲覧可能か
よくある失敗	なりすましを防げない	見えてはいけないものが見える

たとえば、ユーザーAとしてログインできた時点で認証は通っています。
でも、ユーザーBの請求書を見られたら、それは認可の失敗です。

ログインできたのに、なぜ認可が必要なのか

これは初心者が最初に引っかかりやすい点です。

ログインできたということは、誰かは分かった だけです。
しかしサービスでは、そのあとに

一般ユーザー
編集者
管理者
経理担当
外部パートナー

のように立場が分かれます。

同じログイン済みユーザーでも、見えてよいもの・更新してよいものは違います。
だから、認証のあとに認可が必要になります。

どんな場面で認可が出てくるか

認可はかなり広い場面で使われます。

管理画面

管理者だけ設定変更できる
編集者は公開だけできる
閲覧担当は見るだけ

API

読み取りはできるが書き込みは不可
自分のデータだけ取得可能
管理系APIは特定ロールのみ

クラウドや業務システム

どのS3バケットへアクセスできるか
どのAWSリソースを操作できるか
どの顧客情報を見られるか

つまり、認可は 画面の見た目 だけではなく、バックエンドや API 側で必ず判定が必要です。

認可が弱いと起きること

よくあるのは次のような問題です。

1. URLやIDを変えると他人の情報が見える

これは典型的な認可不備です。
ログイン済みでも そのデータに触れてよい人か の判定が抜けている状態です。

2. ボタンを隠しただけで安心してしまう

画面で非表示にしても、API やサーバー側で認可チェックをしないと意味がありません。
見えないだけで、リクエスト自体は送れてしまうことがあります。

3. 管理者権限が広すぎる

全部まとめて admin にすると、運用が雑になりやすいです。
本当は必要な範囲だけに絞ったほうが安全です。

代表的な考え方

RBAC

RBAC は Role-Based Access Control の略で、役割ごとに権限を分ける考え方です。
管理者 編集者 閲覧者 のように、役割を決めてアクセス権を割り当てます。

最初に導入しやすい認可の形で、社内ツールや管理画面でもよく使われます。

ABAC

役割だけでなく、属性で判断する考え方です。
たとえば

所属部署
地域
契約プラン
データの所有者

などを条件にして許可を決めます。

ポリシーベース

AWS IAM のように、どの操作を どの対象へ どの条件で 許すかをポリシーで書く方式です。
柔軟ですが、複雑になると管理が難しくなります。

OAuth 2.0 は認可の話

ここもかなり混ざりやすいです。

OAuth 2.0 は、よくログイン画面で見かけますが、本来は認可の仕組みです。
つまり、本人としてログインさせる技術 というより、ユーザーの権限を限定的に委任する仕組み です。

たとえば

Googleアカウントの連絡先へアクセスする
X の投稿権限を外部アプリへ渡す
YouTube の動画管理を外部ツールから行う

といった場面では、どこまでの権限を渡すか が本質です。
この意味で OAuth 2.0 は認可の話です。

一方、OpenID Connect は、その上に認証の仕組みを足したものです。
ここを分けて理解すると、ログイン系の説明がかなり読みやすくなります。

実装で気をつけること

認可は、仕様上あるだけでは足りません。
実装では少なくとも次を見ます。

画面だけでなくAPI側でも判定する
所有者チェックを入れる
権限ごとのテストを書く
例外ルールを増やしすぎない
デフォルト拒否で考える

OWASP でも、最小権限、deny by default、各リクエストでの検証が重要だとされています。

よくある誤解

1. ログインできたら認可も終わり

違います。
ログイン後にこそ、どこまで許すかの判定が必要です。

2. 管理画面でボタンを隠せば十分

十分ではありません。
サーバー側やAPI側の判定が本体です。

3. OAuth 2.0 は認証の仕組み

厳密には認可の仕組みです。
認証まで含めたいなら OpenID Connect との違いを見る必要があります。

最初に押さえるべきか

最初は次の5つで十分です。

認証は 誰か確認すること
認可は 何をしてよいか決めること
ログイン後にも認可判定が必要
画面で隠すだけでは足りず、API側でも必要
OAuth 2.0 は基本的に認可の話

まとめ

認可は、ユーザーやシステムに どの操作を許すか を決める仕組みです。
認証が 誰かを確認すること なのに対して、認可は 何をしてよいか を判断します。

最初は次の理解で十分です。

認証 = 本人確認
認可 = 操作許可
事故になりやすいのは、認可の抜け漏れ

この切り分けができると、IAM、OAuth 2.0、RBAC、管理画面設計の話がかなり整理しやすくなります。

この記事と一緒に読みたい

参考リンク

Microsoft Learn: Authentication vs. authorization
OWASP: Authorization Cheat Sheet
OWASP: Authentication Cheat Sheet