認証と認可の違いとは？対比表と具体例でわかる仕組み【過去問で対策】

「認証」と「認可」は、システムのセキュリティ設計や運用で毎日のように使う言葉です。ところが「認証と認可の違いを一言で説明してください」と問われると、意外と多くの人が言葉に詰まります。両者は密接に連携して動くため、ひとつの流れとして混同されがちだからです。この記事では、まず認証と認可の違いを対比表と身近な具体例で一気に整理し、そのうえで多要素認証（MFA）・SSO・OAuth 2.0・OpenID Connect（OIDC）といった技術要素と、情報処理技術者試験の過去問までを網羅的に解説します。日常のイメージから試験で問われる論点まで、一本の筋を通して理解しましょう。

CIOとしてアクセス権限の設計を担っていた頃、私が最も神経を使ったのがこの「認証」と「認可」の切り分けでした。ログインできる人（本人だと確認できた人）と、そのシステムで何をしてよい人（権限を持つ人）は同じではありません。後年、新卒エンジニアの研修を担当していた頃には、動作確認を通したい一心で誰にでも管理者権限を付与してしまう新人を実際に目にしました。「ログインできた＝何でも操作してよい」という思い込みは、それほど自然に生まれてしまうのです。誰かを確認する仕組みと、その人に何を許すかを決める仕組みを混同すると、アカウントが一つ乗っ取られただけで被害が一気に広がります。認証と認可を必ず分けて設計するという原則は、試験のためだけでなく、現場で事故を防ぐための実務の基本でもあります。

この記事では以下のことを学べます。

• 認証（誰であるか）と認可（何をしてよいか）の違いと、401・403の意味
• 社員証やホテルの鍵など身近な具体例でつかむ認証と認可の関係
• 本人確認の3要素と、多要素認証（MFA）・SSO・SAMLの役割
• ACL・RBAC・ABAC・OAuth 2.0によるアクセス制御（認可）の仕組み
• 混同しやすいOAuth 2.0とOpenID Connect（OIDC）の違い
• 認可設計の中核となる「最小権限の原則」
• 情報処理技術者試験・SC試験での出題パターンと過去問対策

認証と認可の違いを一言で（対比表と結論）

細かい技術に入る前に、結論から押さえます。認証（Authentication）は「誰であるか」を確認すること、認可（Authorization）は「何をしてよいか」を決めることです。認証で本人だと分かっても、その人がすべての操作を行ってよいわけではありません。逆に、権限を決める前提として「そもそも誰なのか」が確定していなければ認可の判断はできません。この順序と役割の違いを、まず表で見比べてください。

観点	認証（Authentication）	認可（Authorization）
問い	あなたは誰？本当に本人？	あなたは何をしてよい？
目的	本人確認（身元の特定）	アクセス権限の付与・制御
確認するもの	知識情報・所持情報・生体情報	役割・属性・ポリシー
順序	先（入口）	後（認証の結果を前提にする）
代表技術	パスワード、MFA、SSO、SAML、OIDC	ACL、RBAC、ABAC、OAuth 2.0
失敗時の応答例	401 Unauthorized（本人と確認できない）	403 Forbidden（本人だが権限がない）

HTTPステータスコードの名前が紛らわしいのは、学び始めの人がつまずく典型ポイントです。401 Unauthorized は名前に反して「認証の失敗」（あなたが誰か確認できない）を表し、403 Forbidden が「認可の失敗」（本人だとは分かるが、その操作は許可されていない）を表します。「Unauthorized なのに認可の話じゃないのか」と混乱しやすい部分なので、意味で覚えておきましょう。

身近な具体例でつかむ認証と認可

対比表を頭に入れたうえで、日常のシーンに当てはめると腹落ちします。認証と認可は、実は現実世界でも常にセットで機能しています。

オフィスの入館：社員証をかざす（認証）と入れる部屋が違う（認可）

オフィスの入口で社員証をカードリーダーにかざす行為は認証です。「この社員証を持っているのは登録された本人だ」とシステムが確認しています。一方で、同じ社員証でも、一般社員は執務フロアに入れてもサーバールームやセキュリティ区画の扉は開きません。「どの部屋に入れるか」を決めているのが認可です。同じ1枚のカードで、本人確認（認証）と入室許可（認可）という別々の判断が連続して行われています。

ホテルの宿泊：フロントでの本人確認（認証）とルームキー（認可）

ホテルに置き換えても同じ構造です。

1. フロントでの手続き（認証）：身分証明書と予約名を照合して「本人確認」をする
2. ルームキーで特定の部屋に入る（認可）：501号室の鍵は501号室だけ開く。隣室やスタッフルームには入れない

フロントで本人だと確認されても（認証）、館内のすべての部屋に入れるわけではありません。鍵が開ける範囲＝許可された操作（認可）です。

Webサービス：ログインできても他人のデータは見られない

システムでも同じです。社内システムにログイン（認証）できたとしても、自分の勤怠データは操作できる一方、他者の給与情報や管理者向けの設定画面にはアクセスできないよう制限されています。「ログインできた＝何でもできる」ではありません。「誰に」「何を」「どこまで」許可するかを制御するのが認可であり、認証とは独立したプロセスとして機能しています。

認証（Authentication）とは：本人確認の3要素

認証（Authentication）とは、システムにアクセスしようとする主体（ユーザーやデバイスなど）が「主張している通りの正当な本人であるか」を確認するプロセスです。スマートフォンへのログインやWebサービスへのサインインは、すべてこの認証に該当します。システムは、あらかじめ登録された情報とアクセス時に提示された情報を照合して本人確認を行います。ここでは認証を確実にする具体的な手法を整理します。

知識情報・所持情報・生体情報の3要素

システムの本人確認には、主に以下の3要素（ファクター）が用いられます。

• 知識情報（Something you know）：パスワード、PINコード、秘密の質問など「知っている情報」。導入が容易な反面、推測されやすく漏洩リスクが高い
• 所持情報（Something you have）：ICカード、ハードウェアトークン、スマートフォン（SMS認証・認証アプリ）など「持っている情報」。物理的に盗まれない限り安全だが、紛失時の対応が必要
• 生体情報（Something you are）：指紋、顔、静脈、虹彩、音声など「備わっている情報」。偽造が困難で紛失リスクもないが、導入コストが高く、万一漏洩した場合に変更できないという課題がある

多要素認証（MFA）が必須となった背景

サイバー攻撃の高度化により、パスワード（知識情報）のみに依存した単一要素認証では、セキュリティを担保することが極めて困難になっています。フィッシング詐欺やパスワードリスト攻撃によって、パスワードは容易に突破されてしまう可能性があるためです。

そこで重要となるのが多要素認証（MFA：Multi-Factor Authentication）です。MFAは、知識情報・所持情報・生体情報のうち、異なる2つ以上の要素を組み合わせて認証を行う仕組みです。「パスワード（知識情報）でログイン後、登録済みスマートフォン（所持情報）に届くワンタイムパスワードを入力させる」といった構成が代表例です。仮にパスワードが漏洩しても、物理デバイスがなければログインできないため、不正アクセスのリスクを大幅に低減できます。

ここで学び始めの人がひっかかるのが、多要素認証と多段階認証の混同です。「パスワード＋秘密の質問」は2段階を踏みますが、どちらも知識情報なので多要素認証ではなく多段階認証にすぎません。異なる種類のファクターを組み合わせて初めて多要素認証になります。

シングルサインオン（SSO）とSAMLの役割

企業内で多数のシステムやクラウドサービスを利用するようになり、ユーザーがサービスごとに別々のIDとパスワードを管理することは、利便性の低下だけでなく、パスワードの使い回しや単純化というセキュリティリスクも生み出します。

これを解決するのがシングルサインオン（SSO：Single Sign-On）です。SSOは、一度の認証で複数の異なるシステムやサービスを利用できるようにする仕組みです。SSOを実現する代表的なプロトコルがSAML（Security Assertion Markup Language）です。SAMLは、IDプロバイダ（IdP：認証情報を提供する側）とサービスプロバイダ（SP：サービスを提供する側）の間で、ユーザーの認証情報や属性情報をXML形式のメッセージ（アサーション）として安全にやり取りするための標準規格です。企業内で一度認証すれば、SAMLを通じて外部のクラウドサービス（SaaSなど）にも自動ログインできるようになり、利便性とセキュリティを両立できます。

認可（Authorization）とは：アクセス制御の仕組み

認可（Authorization）とは、認証されたユーザーに対して、システム内の特定のリソース（ファイル、データ、機能など）への「アクセス権限を付与すること」です。権限が広すぎればインシデントリスクが高まり、狭すぎれば業務に支障をきたすため、緻密な設計が求められます。認可を実現する代表的な方式を見ていきます。なお各アクセス制御モデルの体系的な比較は、別記事「アクセス制御モデル（DAC・MAC・RBAC）の違い」で詳しく扱っています。

アクセス制御リスト（ACL）とロールベースアクセス制御（RBAC）

リソースへのアクセス権管理として古くから使われてきたのがACL（Access Control List：アクセス制御リスト）です。ファイルやディレクトリなどのリソースに対して「どのユーザーがどの操作を行えるか」をリストで管理します。シンプルですが、ユーザー数やリソースが増えると管理が非常に煩雑になります。

この課題を解決し現在広く採用されているのがRBAC（Role-Based Access Control：ロールベースアクセス制御）です。RBACでは、ユーザーに直接権限を付与するのではなく、「管理者」「一般社員」「ゲスト」といった「ロール（役割）」を作成し、そのロールに権限を割り当てます。ユーザーを適切なロールに所属させることで間接的に権限を付与する形です。人事異動があっても所属ロールを変更するだけで済むため、大規模システムでの管理負荷を大幅に軽減できます。

属性ベースアクセス制御（ABAC）の柔軟性

RBACは強力ですが、「役割」という静的な情報に基づいているため、きめ細やかな制御には限界があります。そこで登場したのがABAC（Attribute-Based Access Control：属性ベースアクセス制御）です。ABACは、次の3種類の属性情報を組み合わせて動的にアクセス可否を判断します。

• ユーザー属性：部署、役職、雇用形態など
• リソース属性：機密レベル、作成日、データ種別など
• 環境属性：アクセス元IPアドレス、時間帯、使用デバイスなど

例えば「経理部の社員（ユーザー属性）は、社内ネットワークから（環境属性）、平日の営業時間内のみ（環境属性）、財務データ（リソース属性）にアクセスできる」といった複雑なポリシーを定義でき、状況に応じた柔軟な認可制御を実現します。「アクセスのたびに属性を評価して都度判断する」という考え方は、ゼロトラストアーキテクチャの設計思想とも密接に結びついています。

OAuth 2.0による安全な権限委譲

Webサービス間でデータを連携する際、ユーザーが自身のパスワードを別のサービスに渡すことなく、特定のデータへのアクセス権のみを安全に付与（委譲）する仕組みが必要です。これを実現する世界標準の認可フレームワークがOAuth 2.0です。

例えば、新しいスケジュール管理アプリ（クライアント）を使い始める際、Googleカレンダー（リソースサーバー）の予定データを読み込む場面を考えます。この時、ユーザーはスケジュール管理アプリにGoogleのパスワードを教える必要はありません。OAuth 2.0の仕組みにより、Google側で認証を行い、「このアプリにカレンダーの読み取り権限を与えますか？」という確認画面（認可コンセント）に同意するだけで連携が完了します。

同意後、スケジュール管理アプリには限定的な権限を持つ「アクセストークン」が発行され、このトークンを使ってGoogleカレンダーのデータにアクセスします。OAuth 2.0は第三者のアプリケーションに対して、安全に「認可」を与えるための仕組みです。

混同しやすい「OAuth 2.0」と「OpenID Connect（OIDC）」の違い

認証と認可の違いを理解したうえで、実務や試験で最も間違いやすいポイントである「OAuth 2.0」と「OpenID Connect（OIDC）」の違いを整理します。ここは「認可の仕組みを認証に流用してよいか」という、本記事の主題そのものが問われる箇所です。

OAuth 2.0は「認可」のフレームワーク

OAuth 2.0はあくまで「認可（権限の委譲）」のためのフレームワークです。発行されるアクセストークンは「対象リソースにアクセスするための鍵」にすぎず、その鍵を持っているのが「誰であるか（ユーザーの身元）」を証明するものではありません。

かつてOAuth 2.0の仕組みを無理やり「認証（ログイン）」に転用しようとする動きがありましたが、アクセストークンは単なる通行証であり身分証の代わりにはならないため、セキュリティ上の脆弱性が指摘されるようになりました。「鍵を持っている＝本人」と早合点する設計は、認証と認可を混同した典型的な悪癖です。

OpenID ConnectはOAuth 2.0を拡張した「認証」プロトコル

OAuth 2.0を認証目的で安全に利用できるよう、OAuth 2.0をベースに拡張されたプロトコルがOpenID Connect（OIDC）です。OIDCの最大の特徴は、アクセストークンに加えてIDトークン（ID Token）が発行される点です。IDトークンはJWT（JSON Web Token）形式でデジタル署名されており、「認証されたユーザーのID情報」や「いつ認証されたか」といった検証可能な本人確認情報が含まれています。クライアントアプリケーションはIDトークンを受け取り、署名を検証することでユーザーが認証済みの本人であることを安全に確認できます。

実際のWebサービスでの使い分け

• OAuth 2.0のユースケース：「アプリAから、SNS（アプリB）に写真を自動投稿する設定をする」→「写真投稿の権限」をアプリAに委譲しているため「認可」
• OpenID Connectのユースケース：「新しいWebサービスに『Googleアカウントでログイン』ボタンを使って会員登録・ログインする」→外部プロバイダが確認した身元情報を受け取って自社サービスに入れているため「認証」

目的が権限の委譲（認可）であればOAuth 2.0、目的が本人確認（認証）であればOIDCを利用するというのが正しい切り分けです。

認証・認可の設計における最小権限の原則

セキュリティ設計において欠かせないのが最小権限の原則（Principle of Least Privilege）です。これは、ユーザーやシステムに対して、業務遂行に必要な最小限の権限のみを付与するという考え方であり、認可設計の中核をなす原則です。

過剰な権限が付与されていると、アカウントが不正に乗っ取られた場合や内部不正が発生した場合に、被害が広範囲に及ぶリスクがあります。例えば、一般社員に管理者権限が付与されていた場合、その社員のアカウントが漏洩するだけで、システム全体が危険にさらされます。新卒エンジニアの頃にありがちなのが、動作確認を優先して安易に全権限（Allow All）を付けてしまう悪癖ですが、これはセキュリティの根本を崩す典型例です。

最小権限の原則を実装する際の具体的な取り組みとしては、次のようなものが挙げられます。

• 業務ごとにロール（役割）を細かく分割し、必要な権限のみを付与する（RBACと組み合わせて設計する）
• 一時的な作業のために付与した権限は、作業完了後に速やかに回収する
• 定期的にアクセス権のレビューを実施し、不要な権限が残っていないか確認する
• 特権アカウント（管理者アカウント）の使用は必要な場面に限定し、通常業務には一般権限を使用する

最小権限の原則は、認証・認可の設計と密接に絡み合っており、情報セキュリティマネジメント試験や応用情報技術者試験でも出題されています。認可の概念とセットで押さえておきましょう。

SC試験での出題パターンと対策

認証と認可は、情報処理安全確保支援士（SC）試験をはじめ高度情報処理技術者試験で頻出のテーマです。午前IIでは用語の定義や技術の対応（どのプロトコルが認証でどれが認可か）を問う4択、午後では認証基盤やSSOの設計事例を読ませて適切な仕組みを選ばせる問題が定番です。ここで実際の過去問をベースに、狙われる論点を確認します。

過去問①：IDトークンとアクセストークンの違い

出典：応用情報技術者試験 令和3年度 春期 午後Ⅰ 問2「Webシステムの認証と認可」より改変

ある企業では、自社で開発する複数のWebサービス（サービスA、サービスB）に対して、共通のID基盤を利用したシングルサインオン（SSO）を導入することになりました。ID基盤にはOpenID Connect（OIDC）を利用し、外部クラウドサービスとのAPI連携にはOAuth 2.0を利用する設計としました。

設問
OIDCにおいて、クライアント（サービスA）がユーザーの認証イベントに関する情報やユーザーの属性情報を受け取るために、認可サーバーから発行されるトークンの名称を答えよ。

回答例
IDトークン（ID Token）

解説
OAuth 2.0ではAPIアクセスのための「アクセストークン」が発行されますが、認証プロトコルであるOIDCでは、これに加えてユーザーの認証結果（誰がいつどのように認証されたか）を内包した「IDトークン」が発行されます。IDトークンは改ざんを検知できるよう、署名付きのJWTフォーマットでやり取りされます。OIDCとOAuth 2.0の違いは試験最頻出ポイントのひとつです。

過去問②：多要素認証（MFA）の要素の組み合わせ

出典：情報セキュリティマネジメント試験 令和4年度 春期 午前 問16 より改変

設問
多要素認証（MFA）を導入する場合、正しい要素の組み合わせとして適切なものはどれか。

• ア：パスワードと秘密の質問の組み合わせ
• イ：パスワードとSMSで送信されるワンタイムパスワードの組み合わせ
• ウ：PINコードとパスワードの組み合わせ
• エ：秘密の質問と生年月日の組み合わせ

回答例
イ

解説
多要素認証（MFA）とは、異なる種類のファクターを2つ以上組み合わせることを指します。ア・ウ・エはいずれも「知識情報（Something you know）」同士の組み合わせであり、これは多要素認証ではなく多段階認証にすぎません。正解のイは、「パスワード（知識情報）」と「SMSのワンタイムパスワード（所持情報）」という異なる種類のファクターを組み合わせているため、多要素認証として成立します。この違いは試験でも細かく問われるため注意が必要です。

過去問③：RBACの説明

出典：基本情報技術者試験 令和元年度 秋期 午前 問38 より改変

設問
ロールベースアクセス制御（RBAC）の説明として、最も適切なものはどれか。

• ア：ユーザーごとにアクセス制御リスト（ACL）を個別に作成し、各ユーザーが直接アクセスできるリソースを管理する
• イ：システムのリソースに対して、時間帯やアクセス元IPアドレスといった環境属性を基にアクセスを制御する
• ウ：あらかじめ定義した役割（ロール）に権限を割り当て、ユーザーをそのロールに所属させることでアクセス権を管理する
• エ：ユーザーの要求に応じてリアルタイムにアクセス権を動的に付与し、使用後は即時に回収する

回答例
ウ

解説
RBACの核心は「ユーザーに直接権限を付与するのではなく、ロール（役割）を介して権限を管理する」点にあります。アはACLの説明、イはABAC（属性ベースアクセス制御）の環境属性に関する説明、エはジャストインタイムアクセス（JIT）に近い概念です。人事異動が多い組織では、担当者が変わってもロールを変更するだけで権限を一括更新できるため、RBACは管理コストの削減にも大きく貢献します。

過去問④：SAMLの役割

出典：応用情報技術者試験 令和5年度 春期 午前 問43 より改変

設問
SAML（Security Assertion Markup Language）に関する記述として、適切なものはどれか。

• ア：ネットワーク機器間でIPアドレスを動的に割り当てるためのプロトコルである
• イ：IDプロバイダとサービスプロバイダの間でユーザーの認証情報をXML形式でやり取りし、SSOを実現するための標準規格である
• ウ：クライアントとサーバー間の通信を暗号化するためのプロトコルである
• エ：Webブラウザのクッキー情報を利用してユーザーを一意に識別する仕組みである

回答例
イ

解説
SAMLは、IDプロバイダ（IdP）とサービスプロバイダ（SP）の間でユーザーの認証アサーション（認証情報・属性情報）をXML形式で安全にやり取りするための標準規格であり、企業でのSSOを実現する際に広く用いられています。アはDHCPの説明、ウはTLSの説明、エはセッション管理に近い概念です。SAMLはクラウドサービス（SaaS）との連携においても重要で、「どのプロトコルが何を実現するか」を正確に紐付けて覚えることが試験攻略のポイントです。

過去問⑤：OAuth 2.0のアクセストークン

出典：情報処理安全確保支援士試験 令和2年度 秋期 午前Ⅱ 問14 より改変

設問
OAuth 2.0において、クライアントアプリケーションがリソースサーバーにアクセスする際に使用するものはどれか。

• ア：IDトークン
• イ：アクセストークン
• ウ：リフレッシュトークン
• エ：認可コード

回答例
イ

解説
OAuth 2.0における各トークンの役割は試験で繰り返し問われます。アクセストークンはリソースサーバーへのアクセスに使用する「鍵」、リフレッシュトークンはアクセストークンの有効期限が切れた際に新しいアクセストークンを取得するために使用します。認可コードは認可コードフローにおいて認可サーバーからクライアントへ一時的に発行されるコードで、これをアクセストークンと交換します。IDトークンはOIDC固有の概念であり、OAuth 2.0単体では発行されません。この4つの違いを整理して覚えることが重要です。

【演習】「認証」と「認可」の違い 理解度チェック（全10問）

認証と認可は、午前IIでは用語の定義や技術との対応（どれが認証でどれが認可か）を問う4択、午後ではSSOや認可委譲を含む設計事例として問われます。定番のひっかけは「多要素認証と多段階認証の混同」「OAuth 2.0を認証と誤認する」「401と403の取り違え」です。以下の練習問題で本記事の理解度を確認してみましょう。選択肢をクリックするとその場で正誤と解説が表示されます。

まとめ：認証と認可の違いを設計に活かす

本記事では、「認証（誰であるかの確認）」と「認可（何をしてよいかの決定）」の違いを、対比表・身近な具体例・技術・過去問を通じて体系的に整理しました。

• 認証は本人確認のプロセス。知識情報・所持情報・生体情報の3要素を組み合わせたMFAやSSOで、安全性と利便性を高める
• 認可は認証されたユーザーへ適切なアクセス権を付与するプロセス。ACL・RBAC・ABAC・OAuth 2.0が代表技術
• OAuth 2.0は認可のフレームワーク。アクセストークンは権限の鍵であり、身元証明にはならない
• OpenID Connect（OIDC）はOAuth 2.0を拡張した認証プロトコル。IDトークンによってユーザーの身元を安全に証明できる
• 最小権限の原則を認可設計に組み込むことで、インシデント発生時の被害範囲を最小化できる

かつてCIOとしてアクセス権限の設計に頭を悩ませた立場から言えば、認証と認可の混同は現場で本当に事故を生みます。「ログインできた人＝何をしてもよい人」ではありません。誰かを確認する仕組み（認証）と、その人に何を許すかを決める仕組み（認可）は、必ず分けて設計する。この基本を押さえれば、試験でも実務でも判断を誤りません。「どの技術がどのレイヤーの課題を解決しているか」を意識しながら知識を整理し、試験本番に臨みましょう。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA 情報処理安全確保支援士試験 過去問題（https://www.ipa.go.jp/shiken/mondai-kaiotu/index.html）
• RFC 6749 The OAuth 2.0 Authorization Framework（https://datatracker.ietf.org/doc/html/rfc6749）
• OpenID Connect Core 1.0（https://openid.net/specs/openid-connect-core-1_0.html）