コンテンツにスキップ

【比較】認証(Authentication)と認可(Authorization)の違い

概要

情報セキュリティの文脈で必ず登場する「認証」と「認可」。この2つの言葉は、システムへのアクセス制御における連続したプロセスですが、その役割は明確に区別されます。しばしば混同されがちですが、安全なシステムを構築するためには、この違いを正確に理解することが不可欠です。

一言で言うと、認証は「システムの入り口のドアを開けるための身分証明」 であり、認可は「ドアの中に入った後、どの部屋に入れるかを決める権限設定」 です。認証（AuthN）は「あなたは誰か」を検証し、認可（AuthZ）は「あなたは何ができるか」を決定します。一般的なフローでは認証が先、認可が後に行われます。

詳細比較

項目 認証 (Authentication / AuthN) 認可 (Authorization / AuthZ)
目的 本人確認 権限付与
問い 「あなたは誰ですか？」 「あなたは何ができますか？」
プロセス ユーザーが提示した情報（ID/パスワード等）が、登録された情報と一致するかを検証する 認証されたユーザーに対して、特定のリソースや操作へのアクセス権を与える・確認する
タイミング 認可の前に行われる 認証の後に行われる
例えるなら 空港での「パスポートと搭乗券の本人確認」 搭乗ゲートでの「ビジネスクラス専用レーンの利用許可」
主な技術 パスワード、多要素認証(MFA)、生体認証、OAuth/OpenID Connect アクセス制御リスト(ACL)、ロールベースアクセス制御(RBAC)、属性ベースアクセス制御(ABAC)

1. 認証 (Authentication / AuthN)

認証は、システムを利用しようとしているユーザーが、本当にその本人であるかを確認するプロセスです。システムは、ユーザーが本人であると主張する際の「証拠」を求め、それが正当なものであるかを検証します。

主な認証要素（多要素認証で組み合わせられる）

認証の強度は、使用する要素の組み合わせによって高まります。

  • 知識情報 (Something you know)
    • ユーザーだけが知っている情報。
    • 例: パスワード、PINコード、秘密の質問
  • 所持情報 (Something you have)
    • ユーザーだけが持っている物理的なモノ。
    • 例: スマートフォン（SMSや認証アプリ）、ハードウェアトークン、ICカード
  • 生体情報 (Something you are)
    • ユーザー固有の身体的特徴。
    • 例: 指紋、顔、虹彩、静脈

なお、同じ要素を2つ重ねる（パスワード＋PIN など）のは多要素認証(MFA)とは見なされず、安全性の向上はわずかです。MFA は「異なる種類の要素」を組み合わせることで強度を高めます。

認証に成功すると、システムは「この通信の相手は、確かにユーザーAさん本人である」と確認できます。 しかし、この時点では、Aさんがシステム内で何をして良いかはまだ決まっていません。

2. 認可 (Authorization / AuthZ)

認可は、認証に成功したユーザーに対して、特定のリソース（ファイル、データ、機能など）へのアクセス権限を付与したり、要求された操作を実行する権限があるかどうかを判断したりするプロセスです。

主なアクセス制御モデル

  • ロールベースアクセス制御 (RBAC)
    • ユーザーに「管理者」「編集者」「閲覧者」などの「役割（ロール）」を割り当て、その役割に応じて権限を管理する一般的な方法。
  • アクセス制御リスト (ACL)
    • 各リソースに対して、どのユーザーがどのような操作（読み取り、書き込みなど）を許可されているかのリストを直接設定する方法。
  • 属性ベースアクセス制御 (ABAC)
    • ユーザーの属性（部署、役職など）、リソースの属性（機密度）、環境（アクセス時間、場所）など、様々な条件を組み合わせて動的にアクセス権を判断する、より柔軟で強力な方法。OWASP は柔軟性・スケーラビリティの観点から、RBAC よりも ABAC や ReBAC（関係ベースアクセス制御）を推奨しています。

認可プロセスにより、システムは「ユーザーAさんは、この記事を閲覧することはできるが、編集や削除はできない」といった判断を下します。

連携のシナリオ例：ブログシステム

  1. アクセス: ユーザーがブログの管理画面URLにアクセスする。
  2. 認証要求: システムはログイン画面を表示し、IDとパスワードの入力を求める。
  3. 認証処理: ユーザーがIDとパスワードを入力。システムはデータベースに登録された情報と照合し、一致すれば認証成功とする。
  4. リソース要求: 認証されたユーザーが、特定の記事を「削除」しようとする。
  5. 認可処理: システムは、そのユーザーに割り当てられたロール（役割）を確認する。「管理者」ロールであれば削除を許可し、「編集者」や「閲覧者」ロールであれば認可を拒否し、エラーメッセージを表示する。

このように、認証と認可は一連の流れの中で連携し、システムのセキュリティを確保しています。認証なくして正当な認可はありえず、認証だけではリソースを安全に保護することはできません。

よくある誤解

  • 「認証と認可は同じもの」は誤り。 認証は「相手が誰か」を確かめる本人確認、認可は「その相手が何をしてよいか」を決める権限判定であり、目的も対象も異なります。OWASP/NIST でも、認証＝「エンティティの身元を検証するプロセス」、認可＝「要求された操作やサービスが特定のエンティティに承認されているかを検証するプロセス」と明確に別概念として定義されています。

  • 「認可は認証の後でしか起こらない」と思い込むのは不正確。 一般的なフローでは認証→認可ですが、認証は必ずしも必須ではありません。OWASP 認可チートシートが指摘するとおり、未認証ユーザーでも公開リソースへのアクセスは「認可されている」ことがあります。順序の典型と必須性は別の話です。

  • 「強いパスワードを2つ要求すれば多要素認証」は誤り。 多要素認証(MFA)は「知識・所持・生体」など異なる種類の要素を組み合わせることに意味があります。パスワード＋PIN のように同一要素を重ねても MFA とは見なされず、得られる安全性の向上はわずかです。

実務での選び分け

  • 「誰か」を確かめたい（ログイン、API クライアント識別） → 認証の領域。パスワード＋MFA、OAuth/OpenID Connect、パスキー(WebAuthn) などを設計する。
  • 「何をしてよいか」を制御したい（操作・リソース単位の制限） → 認可の領域。まず RBAC で役割ごとに大枠を決め、きめ細かい制御が必要なら ABAC/ReBAC を併用する。
  • 公開リソースと保護リソースが混在する → 認証を必須にせず、リソース単位で「未認証でも認可される範囲」と「認証が前提の範囲」を分けて設計する。
  • 設計の原則 → 認証と認可は別レイヤーとして実装する。認証ロジックに認可判定を埋め込むと、権限変更や監査が困難になる。

ひとことまとめ

認証(AuthN)は「あなたは誰か」を検証する本人確認、認可(AuthZ)は「あなたは何ができるか」を決める権限判定であり、典型的には認証が先・認可が後だが、両者は目的も担当レイヤーも異なる別概念です。

出典・参考