認証と認可の違いとは？覚え方や具体例をわかりやすく解説

ITエンジニアにお勧めの本 ↗

おすすめ

エンジニアが知っておきたい思考の整理術 複雑な情報を【理解する】【伝える】テクニック

難易度

実用性

図解

こんな人におすすめ： ドキュメント作成や説明に課題を感じているエンジニア

思考の整理というテーマを、実務ですぐに使える具体的な「技術」として落とし込んだ一冊です。

Amazon 🔴 楽天 📝 書評を読む

ベストセラー

世界一流エンジニアの思考法

難易度

実用性

思考法

こんな人におすすめ： 全エンジニア、生産性を上げたいリーダー

技術スキル以上に大切な「考え方」をアップデートできる。世界基準の効率的な仕事術が学べます。

Amazon 🔴 楽天

文系社会人のためのIT資格の歩き方: 文系のあなたに最適な道をご提案します (YKcreate kiki)

難易度

実用性

キャリア度

こんな人におすすめ： どの資格から取ればいいか迷っている文系出身者

ロードマップが非常に明確。キャリアプランを見据えた、無駄のない学習順序を提案してくれます。

Amazon

エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方

難易度

実用性

コミュ力

こんな人におすすめ： 非エンジニアへの説明に苦労している技術者

「伝える技術」もエンジニアの重要なスキル。相手の視点に立った、具体的な説明のコツが満載です。

Amazon 🔴 楽天

技術広報入門 ー テックブログから始めるエンジニアカルチャーのつくり方

難易度

実用性

独自性

こんな人におすすめ： 技術リーダー・CTO、組織のカルチャー変革に取り組みたい人

テックブログを入口にエンジニア組織の文化をどう設計し、育てていくかという実践論が学べます。

Amazon 🔴 楽天 📝 書評を読む

📚 ITエンジニア向けおすすめ技術書・関連書籍まとめはこちら

Webサービスの開発やセキュリティの勉強をしていると、必ず目にするのが 「認証（Authentication）」 と 「認可（Authorization）」 という2つの言葉です。

日本語でも英語でも名前がよく似ているため、

• 「どっちが本人確認で、どっちが権限のチェックだっけ？」
• 「OAuthOAuth [オーオース]認可のためのオープンな標準プロトコル 2.0 と OpenID Connect（OIDC）って何が違うの？」
• 「HTTPHTTP [エイチティーティーピー]HyperText Transfer Protocol。Webでのデータ転送プロトコルエラーコードの 401 と 403 の使い分けは？」
• 「基本情報技術者試験や実務で迷わない覚え方を知りたい！」

といった疑問を持つ方は非常に多いのではないでしょうか。

本記事では、認証と認可の根本的な違いを、身近な日常の例え（ホテル・免許証・会社の入館証など）や図解、エンジニア向けの実践的な技術解説（OAuth/OIDC・HTTPステータスコード）を交えて徹底的に解説します。

この記事のポイント

• 認証（Authentication / AuthN）：「お前は誰だ？」 を検証する処理（アクセス主体のIdentityの検証・本人確認）
• 認可（Authorization / AuthZ）：「何をしてよいか？」 を判断・制御する処理（権限付与・アクセス可否の判定）
• 一般的なユーザーログインでは「認証」が先で「認可」が後に行われる（誰であるかを確認した後、その主体に許可する操作を判断する）
• OAuth 2.0 は「認可」、 OpenID Connect（OIDC）は「認証」 のための仕組み
• HTTP 401 は「有効な認証情報がない」、HTTP 403 は「アクセス拒否（典型的には権限不足）」を表す

認証と認可の根本的な違い【一目でわかる比較表】

認証と認可の最も本質的な違いは、「対象（相手が誰か）」を確認しているのか、それとも 「行動（何をしてよいか）」を許可しているのか という点にあります。

1
【認証と認可の基本的な流れ】
2
 ユーザー
3
   │
4
   ▼
5
 [ ① 認証 (Authentication) ] ──▶ 「あなたは山田さんですね！（本人確認）」
6
   │
7
   ▼
8
 [ ② 認可 (Authorization)  ] ──▶ 「山田さんには【管理者権限】を与えます！（権限付与）」
9
   │
10
   ▼
11
 対象のリソースへアクセス可能！

認証と認可の詳細比較表

身近な例えで絶対に忘れない！認証と認可のイメージ

「どうしてもどっちがどっちか混同してしまう…」という方のために、日常生活の身近な3つのシチュエーションで例えてみましょう。

例①：ホテルのフロントと客室カードキー

最も直感的でわかりやすいのが、ホテルのチェックインです。

1
【ホテルの例】
2
① フロントで名前を名乗り、予約確認・身分証提示 ──▶ 【 認証 】
3
② 「301号室のカードキー」を受け取り、入室する ───▶ 【 認可 】

1. 認証（Authentication）： ホテルのフロントに行き、「予約した佐藤です」と名乗り、宿泊者名簿への記入や身分証明書の提示を行います。「予約した本人であること」をフロントが確認する行為が認証です。
2. 認可（Authorization）： 本人確認が完了すると、フロントから「301号室のカードキー」を渡されます。このカードキーは「301号室の扉を開けて中に入る権限」を持っています。しかし、隣の302号室や従業員専用室を開ける権限はありません。このように「どこに入ってよいか」を決めるのが認可です。

例②：運転免許証と自動車の運転

身分証明書としての運転免許証も、認証と認可の両方の概念に対応しています。

• 認証（本人であることの確認・照合）： 警察官や窓口の担当者が、免許証に記載された「顔写真」「氏名」と提示した本人を照合し、「この人物が免許証の持ち主本人である」と検証・確認する行為。
• 認可（運転してよいという許可・権限）： 免許証の「免許の種類」欄に「普通」「大型」「原付」などと記載されていること。公安委員会から「公道で特定の自動車を運転する権限が与えられている」ことを示し、運転可否の判断基準となります。

例③：オフィスの入館ゲートとサーバールーム

企業のセキュリティシステムでも、明確に認証と認可が分かれています。

1. 認証： ビルのエントランスゲートで社員証カードをピッとタッチし、「この会社の社員である」と認証されて社内に入館する。
2. 認可： 社内の一般執務室には入れますが、機密データを管理する「サーバールーム」や「役員室」のドアは、システム管理者や役員など特定の権限を持つ社員証でしか解錠できません。

認証（Authentication）の仕組みと具体例

認証とは、アクセスを求めているユーザーや端末、システムなどの主体が「本当に主張通りのIdentity（本人・正当な主体）であるか」を検証するプロセスです。

認証要素の種類（多要素認証：MFA）

セキュリティの世界では、認証に用いる情報は代表的に以下の3種類に分類されます（従来の「認証の3要素」）。

1
【認証の3要素】
2
┌───────────────────────────────────────────────┐
3
│ ① 知識情報（Something you know）              │
4
│    パスワード、暗証番号（PIN）、秘密の質問    │
5
├───────────────────────────────────────────────┤
6
│ ② 所持情報（Something you have）              │
7
│    認証アプリ（OTP）、セキュリティキー、ICカード│
8
├───────────────────────────────────────────────┤
9
│ ③ 生体情報（Something you are）               │
10
│    指紋、顔認証、虹彩、静脈                   │
11
└───────────────────────────────────────────────┘

• 単要素認証（Single-Factor Authentication）： 上記のうち1つの要素だけ（例：パスワードのみ）で認証を行うこと。パスワード漏洩時に不正ログインされるリスクがあります。
• 多要素認証（Multi-Factor Authentication / MFAMFA [エムエフエー]Multi-Factor Authentication。二要素以上の複数の異なる認証手段を組み合わせる多要素認証）： 異なる2つ以上の要素（例：「パスワード（知識）」＋「認証アプリのワンタイムコードやセキュリティキー（所持）」）を組み合わせて認証すること。セキュリティ強度が飛躍的に高まります。 ※SMSによるワンタイムコード認証にはSIMスワップや番号乗っ取りなどのリスクがあるため、より強固な認証方式として、専用の認証アプリ（TOTP）やセキュリティキーなどが広く利用されています。 ※「パスワード」＋「PINコード」のように同一要素の組み合わせは、要素数としては1つのため「多段階認証」であっても「多要素認証」ではありません。

代表的な認証技術・プロトコル

• ID / パスワード認証：最も基本的な知識認証。
• Passkeys（パスキー）：WebAuthn / FIDO標準に基づく、公開鍵暗号を利用した安全なパスワードレス認証。端末の生体認証（指紋・顔）やPIN、デバイスパスコードなどによるユーザー確認と組み合わせて利用されます。
• OpenID Connect（OIDC）：OAuth 2.0の仕組みをベースに、ユーザーの認証情報（IDトークン）を安全にやり取りするための業界標準プロトコル。
• SAML（Security Assertion Markup Language）：主に企業のシングルサインオン（SSO）で利用されるXMLXML [エックスエムエル]eXtensible Markup Language。汎用マークアップ言語ベースの認証・ID連携規格。認証結果だけでなく所属や権限などの属性情報（認可情報）も合わせてやり取りできる特徴があります。

認可（Authorization）の仕組みと具体例

認可とは、特定の主体に対して「どのリソースに対して、どのような操作（閲覧・編集・削除など）を実行してよいか」を判断・決定・制御するプロセスです。

主要なアクセス制御モデル

システム内で認可ルールをどのように定義するかには、いくつかの代表的な設計パターン（モデル）が存在します。

1. RBAC（ロールベースアクセス制御 / Role-Based Access Control）

ユーザーに「役職」や「役割（ロール）」を割り当て、ロール単位で権限を付与する最も一般的な方式です。

• 管理者（Admin）：すべてのデータの閲覧・作成・編集・削除、ユーザー管理が可能
• 編集者（Editor）：記事の作成・編集・公開が可能（ユーザー管理は不可）
• 閲覧者（Viewer）：データの閲覧のみ可能（作成・変更は不可）

2. ABAC（属性ベースアクセス制御 / Attribute-Based Access Control）

ユーザーの属性だけでなく、リソースの属性、アクセス環境（時間帯、IPIP [アイピー]Internet Protocol。インターネット通信の基本プロトコルアドレス、接続元の端末セキュリティ状態など）を総合的に評価して動的にアクセスを判断する高度な認可方式です（ゼロトラストセキュリティなどで重視されます）。

3. ReBAC（関係性ベースアクセス制御 / Relationship-Based Access Control）

ユーザーとリソースの「関係性（グラフ構造・親子関係）」に基づいてアクセス権を判定する最新の認可モデルです（Google ZanzibarやGitHubGitHub [ギットハブ]Gitリポジトリをホストし、共同開発を支援するWebサービス、Google Driveなどのきめ細かな権限管理で活用されています）。

• 例：「ドキュメントの作成者（Owner）」「同じフォルダを共有されたチームのメンバー（Viewer）」「親組織の管理者」といったエンティティ間の関係性から動的に認可を判断します。

代表的な認可技術・プロトコル

1
【アクセストークンによる認可の流れ】
2
[ クライアントアプリ ] ──( アクセストークンを提示 )──▶ [ APIサーバー ]
3
                                                        │
4
                                                        ▼
5
                                       「このトークンには 'read:profile' と
6
                                        'write:posts' のスコープ（権限）が
7
                                        認められていますね。許可します！」

• OAuth 2.0：サードパーティ製アプリにユーザーのパスワードを教えることなく、限定されたリソースへのアクセス権限（アクセストークン）を委譲するための業界標準仕様。
• LinuxLinux [リナックス / ライナックス]オープンソースのOSカーネルのファイルパーミッション（rwx）：ファイルの所有者（Owner）、グループ（Group）、その他（Others）に対して「読み取り（r）」「書き込み（w）」「実行（x）」の権限を割り当てるOSOS [オーエス]Operating System。基本ソフトウェアレベルの認可。
• AWSAWS [エーダブリュエス]Amazon Web Services。Amazonのクラウドサービス IAM（Identity and Access Management）ポリシー：AWS上のクラウドサービス（S3、EC2など）に対して、誰がどのようなAPIAPI [エーピーアイ]Application Programming Interface。異なるソフトウェア間の接続口操作を実行できるかをJSONJSON [ジェイソン]JavaScript Object Notation。軽量データ交換フォーマット形式で細かく定義する認可設定。

【エンジニア必見】認証と認可の最重要トピック

エンジニアが実務や学習で最もつまずきやすい「OAuth 2.0 と OIDC の違い」と「HTTP 401 と 403 の使い分け」を詳しく掘り下げます。

① OAuth 2.0 と OpenID Connect（OIDC）の決定的な違い

よく「Googleでログイン」や「GitHubでサインイン」といったソーシャルログイン機能を見かけます。これらに関連する技術が OAuth 2.0 と OpenID Connect（OIDC） です。

1
【OAuth 2.0 と OIDC の関係性】
2
┌───────────────────────────────────────────────┐
3
│ OpenID Connect (OIDC)   ──▶ 【 認証 (AuthN) 】 │
4
│ （「あなたは誰か」を証明する IDトークンを発行） │
5
├───────────────────────────────────────────────┤
6
│ OAuth 2.0               ──▶ 【 認可 (AuthZ) 】 │
7
│ （「リソースへのアクセス」を許可する           │
8
│   アクセストークンを発行）                    │
9
└───────────────────────────────────────────────┘

OAuth 2.0 は「認可」のための仕様

OAuth 2.0は、「自分のGoogleドライブにある写真を、プリントサービスアプリにアクセスさせる」といったように、パスワードを渡さずにリソースのアクセス権（アクセストークン）を第三者アプリへ委譲するための認可プロトコルです。

※OAuth 2.0単体には「ユーザーが誰であるか（本人確認・プロフィール）」を標準的に安全に伝える仕様は含まれていません。

OpenID Connect（OIDC）は「認証」を行うための拡張仕様

OAuth 2.0の仕組みをベースにして、その上に**「ユーザーが認証されたことの証明（IDトークン / JWTJWT [ジェイダブリュティー / ジョット]JSON Web Token。認証情報をJSONで表現するトークン方式形式）」をやり取りする規格を上乗せしたものがOpenID Connect（OIDC）**です。

[!NOTE] コラム：最新のセキュリティ動向「OAuth 2.1」とは？
OAuth 2.0は広く普及していますが、策定から年月が経ち、安全な運用のためのベストプラクティスを統合した OAuth 2.1 の標準化が進められています。 主な変更点として、認可コード横取り攻撃を防ぐ PKCE（Proof Key for Code Exchange）の必須化 や、セキュリティリスクの高い インプリシットグラント（Implicit Grant）およびパスワードグラントの廃止 などが含まれます。

② HTTP 401 Unauthorized と 403 Forbidden の違い

Web開発者がAPIやWebページのエラーハンドリングを実装する際、正しく押さえておくべき仕様がHTTPステータスコードの 401 と 403 の違いです。

1
【HTTP 401 と 403 の一般的な判定フロー】
2
 リクエスト受信
3
   │
4
   ├─▶ 有効な認証情報がない（未認証/無効） ──▶ 【 401 Unauthorized 】
5
   │                                           （「有効な認証情報を提示してください」）
6
   ▼
7
 認証情報あり（認証OK）
8
   │
9
   ├─▶ 権限が不足している / アクセス拒否 ──▶ 【 403 Forbidden 】
10
   │                                           （「要求は理解したがアクセスを許可しない」）
11
   ▼
12
 権限あり（認可OK） ────────────────────────▶ 【 200 OK 】

401 Unauthorized ＝ 「有効な認証情報がない（未認証）」

• 状態：リクエストに有効な認証情報（Authorizationヘッダー、APIトークン、セッションCookieなど）が含まれていない、または期限切れ・無効である。
• 意味：「有効な認証情報が提示されていないため、アクセスを受け付けられません。正しい認証情報を提示してください」。
• 注意点（名前の罠）：ステータス名は「Unauthorized（認可されていない）」となっていますが、**RFC仕様上の意味は「有効な認証資格情報（authentication credentials）を欠いている」**状態を指します。実質的に「未認証（Unauthenticated）」に近いエラーです。

403 Forbidden ＝ 「要求は理解したが、アクセスを許可しない」

• 状態：サーバーはリクエストを理解したものの、実行を拒否している状態。
• 意味：「要求内容は理解できましたが、このリクエストの実行・アクセスは許可できません」。
• 典型的なケース：認証済みのユーザーだが、そのリソースに対する操作権限が付与されていない場合（一般ユーザーが管理者用APIを叩いた場合など）に使用されます。
• 補足：認証とは無関係な理由（IP制限や地域制限など）で拒否される場合にも使われます。また、機密リソースの存在自体を秘匿したい場合は、403の代わりに404 Not Foundを返す設計も仕様上認められています。

③ 開発者が最も警戒すべき認可の脆弱性：BOLA（Broken Object Level Authorization）

認証と認可の違いを混同した開発者が起こしやすい重大なセキュリティ欠陥が BOLA（オブジェクトレベルの認可の不備） です。OWASP API Security Top 10でも長年第1位のリスクとして警戒されています。

1
【BOLAの脆弱性の発生イメージ】
2
 ユーザーA（正常にログイン・認証済み）
3
   │
4
   ▼ リクエスト送信
5
 GET /api/users/1001/orders （自分の注文履歴：閲覧成功）
6
   │
7
   ▼ パラメータのIDを他人のものに書き換えて送信
8
 GET /api/users/1002/orders （ユーザーBの注文履歴）
9
   │
10
   ▼ サーバー側の処理
11
 ❌ 認可不備：「ログイン済みのユーザーだからOK」と通してしまい、他人のデータが漏洩
12
 ⭕ 正常な認可：「ログイン中のユーザーAは、ID:1002のデータを閲覧する権限があるか？」を検証して403を返す

「ログイン（認証）されているから安全」と過信し、「そのユーザーが、指定されたデータ（オブジェクト）に対して操作権限（認可）を持っているか」の検証を怠ると、他人の個人情報や注文履歴が簡単に閲覧・改ざんされてしまいます。

④ 組織的なアクセス権管理：過剰な権限付与とガバナンス（IGA）

認可の課題はプログラムの実装だけでなく、企業や組織の運用面でも極めて重要です。

• 過剰な権限付与（Privilege Creep）のリスク： 異動やプロジェクト終了に伴う権限の剥奪（デプロビジョニング）を怠ると、不要な権限が蓄積した「特権アカウント」が放置されます。アカウントが乗っ取られた際、被害が全社規模に拡大する原因になります。
• 職務分掌（SoD: Segregation of Duties）： 「取引先の登録権限」と「支払い承認権限」を同一人物に持たせないように認可ルールを分離し、不正や誤操作を組織的に防ぐ内部統制の原則です。
• アイデンティティ・ガバナンス＆管理（IGA）： エンタープライズ環境では、**「最小権限の原則（Principle of Least Privilege）」**に基づき、定期的な権限の棚卸しや自動プロビジョニングを行うIGAの仕組みが不可欠となっています。

認証と認可に関するよくある質問（FAQ）

Q1. なぜ「AuthN」「AuthZ」と略されるの？ 語源や覚え方は？

A. どちらも「Auth」で始まり混同しやすいため、特徴的な文字（Authenticationの N、Authorizationの Z）を取って区別しています。また、英単語の核（語源）を意識すると直感的に覚えられます。

英語圏のエンジニアコミュニティやセキュリティ規格のドキュメントでは、スペースの節約や誤認防止のため、以下のように省略表記（オースエヌ / オースズィー）されるのが一般的です。

• AuthN ＝ Authentication（認証）
  • 核となる単語は Authentic（本物の、正真正銘の）。「対象が本物であることを証明・確認する ➔ 本人確認・主体の検証」
• AuthZ ＝ Authorization（認可）
  • 核となる単語は Authority（権限、当局）や Author（創作者、権威者）。「権限や許可を与える ➔ 権限付与・アクセス判定」

Q2. 個人の本人確認（ユーザー認証）なしでアクセス制御（認可）を行うことはある？

A. はい、あります。特定の個人を識別・認証せず、「有効なキーやトークン、資格を持っていること」に基づいて操作やアクセスを許可するケースです。

厳密には「クライアントの識別・認証」や「所持情報の検証」が行われている場合もありますが、エンドユーザー個人の認証を行わない例として以下のようなケースがあります。

• APIキー（システム・サービス間連携）：個々のユーザーを認証するのではなく、APIキーを持つクライアント（プログラムやシステム）を識別・認証し、そのキーに付与されたアクセス権に基づいてAPIの利用を許可します。
• 共有リンク（URLURL [ユーアールエル]Uniform Resource Locator。Webページのアドレスを知っている全員にアクセス許可）：利用者の個人Identityを特定（認証）せず、「秘密のトークンを含むURLを知っていること」自体をアクセス条件として閲覧などを許可する方式です。
• 映画館の紙のチケット：購入者が誰であるかを特定（認証）しなくても、「有効なチケットを持っていること」を条件にシアターへの入場を許可します。

Q3. 基本情報技術者試験やセキュリティ試験で押さえておきたいポイントは？

A. 主に「認証要素の3分類」「多要素認証（MFA）」「OAuth/SAML/OIDCの役割」「アクセス制御モデル（RBAC）」を押さえておくと理解が深まります。

試験では以下のような形で問われることが多いため、整理して覚えておきましょう。

1. 認証の要素：ワンタイムパスワード（所持）＋パスワード（知識）が多要素認証に該当することを見分ける問題。
2. 認可と認証の区別：OAuth 2.0が「認可の委譲」であり、OpenID Connectが「認証の連携」であるというプロトコルの目的を問う問題。
3. アクセス権管理：最小権限の原則（Principle of Least Privilege）に基づき、ロール（RBAC）に応じて必要最小限の権限のみを付与する設計原則。

まとめ：認証と認可の違いを総復習

認証と認可は、WebサービスやITシステムのセキュリティを構築する上で最も根幹となる概念です。

最後に、重要ポイントをチェックリストでおさらいしましょう。

今回のまとめチェックリスト

• 認証（Authentication / AuthN） は「お前は誰だ？」（Identityの検証・本人確認）
• 認可（Authorization / AuthZ） は「何をしてよいか？」（アクセス可否・権限の判断）
• 一般的なWebサービスでは 「① 認証（主体を確認）」 ➔ 「② 認可（操作を判断）」 の順で考えると理解しやすい
• 認証要素の3分類は 「知識情報」「所持情報」「生体情報」
• OAuth 2.0 は認可のための仕様、OpenID Connect（OIDC）は認証のための仕様
• HTTP 401 は認証情報の欠如・無効、HTTP 403 はアクセス拒否（典型的には権限不足）

この2つの違いを正しく理解し、安全で使いやすいWebサービスやAPIの設計・開発に役立ててください！

おすすめ この記事に関連する技術本

世界一流エンジニアの思考法

Amazon 🔴 楽天

Kindle Unlimited

IT専門書も30日間無料で読み放題

1冊数千円する専門書から、ビジネス書、実用書、雑誌まで幅広いジャンルが定額で読み放題。ITスキルの向上はもちろん、日々の情報収集や教養を深めるのにも最適です。

• 📚 技術書も月額定額で読み放題
• 📱 マルチデバイス対応
• ✨ 30日間の無料体験

無料で30日間試してみる

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →