システムのセキュリティ設計や運用において日常的に使われる用語でありながら、いざ違いを問われると混同しがちなのが「認証」と「認可」です。情報処理技術者試験でも頻出のテーマであり、正確な概念の理解なしには正答に辿り着けません。本記事では、認証と認可の定義・具体的な技術要素から、OAuth 2.0・OpenID Connect（OIDC）といった関連プロトコルまでを網羅的に解説します。実際の過去問も交えながら、実践的な知識をしっかりと身につけましょう。
1. 「認証」と「認可」の決定的な違い
システムの安全性を確保するためには、アクセスしようとするユーザーが本当に本人であるかを確認し、そのユーザーに対して適切な操作のみを許可する仕組みが欠かせません。この一連のプロセスにおいて、「認証」と「認可」は全く異なる役割を担っています。まずは各用語の定義から整理します。
1.1 認証（Authentication）とは「誰であるか」を確認すること
認証（Authentication）とは、システムにアクセスしようとする主体（ユーザーやデバイスなど）が、「主張している通りの正当な本人であるか」を確認するプロセスです。「あなたは誰ですか？本当にその人ですか？」という問いに答える確認作業といえます。
スマートフォンへのログインやWebサービスへのサインインは、すべてこの認証プロセスに該当します。システムは、あらかじめ登録された情報とアクセス時に提示された情報を照合して本人確認を行います。提示される情報には次の3種類があります。
- 知識情報：パスワードやPINコードなど「知っている情報」
- 所持情報：スマートフォンやICカードなど「持っている情報」
- 生体情報：指紋や顔認証など「備わっている情報」
これらを組み合わせることで、認証の安全性を高めることができます。
1.2 認可（Authorization）とは「何ができるか」を決定すること
認可（Authorization）とは、認証されたユーザーに対して、システム内の特定のリソース（ファイル、データ、機能など）への「アクセス権限を付与すること」です。「あなたにはこの操作を行う権限がありますか？」という問いへの判断と許可のプロセスと言えます。
認証によってシステムに入れたとしても、すべての情報を自由に閲覧・編集できるわけではありません。一般社員がシステムにログイン（認証）した場合、自分の勤怠データは操作できますが、他者の給与情報やシステム設定画面にはアクセスできないよう制限されています。「誰に」「何を」「どこまで」許可するかを制御するのが認可の役割です。
1.3 日常生活で例える認証と認可
ホテルへの宿泊を例に考えると、二つの違いが明確になります。
- フロントでの手続き（認証）：身分証明書と予約名を照合して「本人確認」をする
- ルームキーを使って特定の部屋に入る（認可）：501号室の鍵で501号室だけ入れる。隣室やスタッフルームには入れない
システムにおいても「システムに入るための確認（認証）」と「システム内で許可された操作（認可）」は、独立したプロセスとして機能しています。
2. システムにおける認証の仕組みと重要技術
認証プロセスについて、具体的な実現手法と最新トレンドを解説します。本人確認をいかに確実に行い、不正アクセスを防ぐかが問われる領域です。
2.1 知識情報・所持情報・生体情報による3要素認証
システムの本人確認には、主に以下の3要素（ファクター）が用いられます。
- 知識情報（Something you know）：パスワード、PINコード、秘密の質問など。導入が容易な反面、推測されやすく漏洩リスクが高い
- 所持情報（Something you have）：ICカード、ハードウェアトークン、スマートフォン（SMS認証・認証アプリ）など。物理的に盗まれない限り安全だが、紛失時の対応が必要
- 生体情報（Something you are）：指紋、顔、静脈、虹彩、音声など。偽造が困難で紛失リスクもないが、導入コストが高く、万一漏洩した場合に変更不能という課題がある
2.2 多要素認証（MFA）が必須となっている背景
サイバー攻撃の高度化により、パスワード（知識情報）のみに依存した単一要素認証では、セキュリティを担保することが極めて困難になっています。フィッシング詐欺やパスワードリスト攻撃によって、パスワードは容易に突破されてしまう可能性があるためです。
そこで重要となるのが多要素認証（MFA：Multi-Factor Authentication）です。MFAは、知識情報・所持情報・生体情報のうち、異なる2つ以上の要素を組み合わせて認証を行う仕組みです。「パスワード（知識情報）でログイン後、登録済みスマートフォン（所持情報）に届くワンタイムパスワードを入力させる」といった構成が代表例です。仮にパスワードが漏洩しても、物理デバイスがなければログインできないため、不正アクセスのリスクを大幅に低減できます。
2.3 シングルサインオン（SSO）とSAMLの役割
企業内で多数のシステムやクラウドサービスを利用するようになった現代、ユーザーがサービスごとに別々のIDとパスワードを管理することは、利便性の低下だけでなく、パスワードの使い回しや単純化というセキュリティリスクも生み出します。
これを解決するのがシングルサインオン（SSO：Single Sign-On）です。SSOは、一度の認証で複数の異なるシステムやサービスを利用できるようにする仕組みです。
SSOを実現する代表的なプロトコルがSAML（Security Assertion Markup Language）です。SAMLは、IDプロバイダ（IdP：認証情報を提供する側）とサービスプロバイダ（SP：サービスを提供する側）の間で、ユーザーの認証情報や属性情報をXML形式のメッセージ（アサーション）として安全にやり取りするための標準規格です。企業内で一度認証すれば、SAMLを通じて外部のクラウドサービス（SaaSなど）にも自動ログインできるようになり、利便性とセキュリティを両立できます。
3. システムにおける認可の仕組みと重要技術
認証されたユーザーに対して適切な権限を割り当てる「認可」の仕組みを解説します。権限が広すぎればインシデントリスクが高まり、狭すぎれば業務に支障をきたすため、緻密な設計が求められます。
3.1 アクセス制御リスト（ACL）とロールベースアクセス制御（RBAC）
リソースへのアクセス権管理として古くから使われてきたのがACL（Access Control List：アクセス制御リスト）です。ファイルやディレクトリなどのリソースに対して「どのユーザーがどの操作を行えるか」をリストで管理します。シンプルですが、ユーザー数やリソースが増えると管理が非常に煩雑になります。
この課題を解決し現在広く採用されているのがRBAC（Role-Based Access Control：ロールベースアクセス制御）です。RBACでは、ユーザーに直接権限を付与するのではなく、「管理者」「一般社員」「ゲスト」といった「ロール（役割）」を作成し、そのロールに権限を割り当てます。ユーザーを適切なロールに所属させることで間接的に権限を付与する形です。人事異動があっても所属ロールを変更するだけで済むため、大規模システムでの管理負荷を大幅に軽減できます。
3.2 属性ベースアクセス制御（ABAC）の柔軟性
RBACは強力ですが、「役割」という静的な情報に基づいているため、きめ細やかな制御には限界があります。そこで登場したのがABAC（Attribute-Based Access Control：属性ベースアクセス制御）です。
ABACは、次の3種類の属性情報を組み合わせて動的にアクセス可否を判断します。
- ユーザー属性：部署、役職、雇用形態など
- リソース属性：機密レベル、作成日、データ種別など
- 環境属性：アクセス元IPアドレス、時間帯、使用デバイスなど
例えば「経理部の社員（ユーザー属性）は、社内ネットワークから（環境属性）、平日の営業時間内のみ（環境属性）、財務データ（リソース属性）にアクセスできる」といった複雑なポリシーを定義でき、状況に応じた柔軟な認可制御を実現します。
3.3 OAuth 2.0による安全な権限委譲
Webサービス間でデータを連携する際、ユーザーが自身のパスワードを別のサービスに渡すことなく、特定のデータへのアクセス権のみを安全に付与（委譲）する仕組みが必要です。これを実現する世界標準の認可フレームワークがOAuth 2.0です。
例えば、新しいスケジュール管理アプリ（クライアント）を使い始める際、Googleカレンダー（リソースサーバー）の予定データを読み込む場面を考えます。この時、ユーザーはスケジュール管理アプリにGoogleのパスワードを教える必要はありません。OAuth 2.0の仕組みにより、Google側で認証を行い、「このアプリにカレンダーの読み取り権限を与えますか？」という確認画面（認可コンセント）に同意するだけで連携が完了します。
同意後、スケジュール管理アプリには限定的な権限を持つ「アクセストークン」が発行され、このトークンを使ってGoogleカレンダーのデータにアクセスします。OAuth 2.0は第三者のアプリケーションに対して、安全に「認可」を与えるための仕組みです。
4. 混同しやすい「OAuth 2.0」と「OpenID Connect（OIDC）」の違い
「認証」と「認可」の概念を理解した上で、実務や試験で最も間違いやすいポイントである「OAuth 2.0」と「OpenID Connect（OIDC）」の違いを整理します。
4.1 OAuth 2.0は「認可」のフレームワーク
OAuth 2.0はあくまで「認可（権限の委譲）」のためのフレームワークです。発行されるアクセストークンは「対象リソースにアクセスするための鍵」にすぎず、その鍵を持っているのが「誰であるか（ユーザーの身元）」を証明するものではありません。
かつてOAuth 2.0の仕組みを無理やり「認証（ログイン）」に転用しようとする動きがありましたが、アクセストークンは単なる通行証であり身分証の代わりにはならないため、セキュリティ上の脆弱性が指摘されるようになりました。
4.2 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トークンを受け取り、署名を検証することでユーザーが認証済みの本人であることを安全に確認できます。
4.3 実際のWebサービスでの使われ方の違い
- OAuth 2.0のユースケース：「アプリAから、SNS（アプリB）に写真を自動投稿する設定をする」→「写真投稿の権限」をアプリAに委譲しているため「認可」
- OpenID Connectのユースケース：「新しいWebサービスに『Googleアカウントでログイン』ボタンを使って会員登録・ログインする」→外部プロバイダが確認した身元情報を受け取って自社サービスに入れているため「認証」
目的が権限の委譲（認可）であればOAuth 2.0、目的が本人確認（認証）であればOIDCを利用するというのが正しい切り分けです。
5. 【過去問演習】認証・認可・関連プロトコルの頻出問題
ここまでの知識を基に、実際の試験でどのように問われるかを過去問と解説で確認します。
過去問①：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/SSLの説明、エはセッション管理に近い概念です。SAMLはクラウドサービス（SaaS）との連携においても重要で、「どのプロトコルが何を実現するか」を正確に紐付けて覚えることが試験攻略のポイントです。
過去問⑤：OAuth 2.0のアクセストークン
出典：情報処理安全確保支援士試験 令和2年度 秋期 午前Ⅱ 問14 より改変
設問
OAuth 2.0において、クライアントアプリケーションがリソースサーバーにアクセスする際に使用するものはどれか。
- ア：IDトークン
- イ：アクセストークン
- ウ：リフレッシュトークン
- エ：認証コード
回答例
イ
解説
OAuth 2.0における各トークンの役割は試験で繰り返し問われます。アクセストークンはリソースサーバーへのアクセスに使用する「鍵」、リフレッシュトークンはアクセストークンの有効期限が切れた際に新しいアクセストークンを取得するために使用します。認証コードは認可コードフローにおいて認可サーバーからクライアントへ一時的に発行されるコードで、これをアクセストークンと交換します。IDトークンはOIDC固有の概念であり、OAuth 2.0単体では発行されません。この4つの違いを整理して覚えることが重要です。
6. 認証・認可の設計における最小権限の原則
セキュリティ設計において欠かせないのが最小権限の原則（Principle of Least Privilege）です。これは、ユーザーやシステムに対して、業務遂行に必要な最小限の権限のみを付与するという考え方です。
過剰な権限が付与されていると、アカウントが不正に乗っ取られた場合や内部不正が発生した場合に、被害が広範囲に及ぶリスクがあります。例えば、一般社員に管理者権限が付与されていた場合、その社員のアカウントが漏洩するだけで、システム全体が危険にさらされます。
最小権限の原則を実装する際の具体的な取り組みとしては、次のようなものが挙げられます。
- 業務ごとにロール（役割）を細かく分割し、必要な権限のみを付与する（RBACと組み合わせて設計する）
- 一時的な作業のために付与した権限は、作業完了後に速やかに回収する
- 定期的にアクセス権のレビューを実施し、不要な権限が残っていないか確認する
- 特権アカウント（管理者アカウント）の使用は必要な場面に限定し、通常業務には一般権限を使用する
最小権限の原則は、認証・認可の設計と密接に絡み合っており、情報セキュリティマネジメント試験や応用情報技術者試験でも出題されています。認可の概念とセットで押さえておきましょう。
【練習問題】「認証」と「認可」の違いを過去問で確認しよう
ここまで「認証」と「認可」の基本的な違いや、関連する技術について学んできました。知識をしっかりと定着させるために、実際の情報処理技術者試験の過去問をベースにした練習問題に挑戦してみましょう。
選択肢をクリックするとその場で正誤と詳しい解説が表示されます。迷ったときは「ヒントを見る」機能も活用しながら、全10問の完全理解を目指してください！
まとめ
本記事では、「認証（誰であるかの確認）」と「認可（何ができるかの決定）」の違いを軸に、関連する技術・プロトコル・過去問を通じて体系的に整理しました。
- 認証は、パスワードや生体認証などを用いて本人を確認するプロセス。MFAやSSOといった技術と組み合わせて安全性・利便性を高める
- 認可は、RBACやABAC・OAuth 2.0などを用いて、認証されたユーザーに対して適切なアクセス権を付与するプロセス
- OAuth 2.0は認可のフレームワーク。発行されるアクセストークンは権限の鍵であり、身元証明にはならない
- OpenID Connect（OIDC）はOAuth 2.0を拡張した認証プロトコル。IDトークンによってユーザーの身元を安全に証明できる
- 最小権限の原則を認可設計に組み込むことで、インシデント発生時の被害範囲を最小化できる
これらの概念を正確に理解することは、安全なシステムアーキテクチャを設計・評価するための土台となります。「どの技術がどのレイヤーの課題を解決しているか」を常に意識しながら知識を整理し、試験本番に臨みましょう。