情報処理試験を勉強していると、「OAuthって認証？認可？何が違うの？」と混乱しがちです。
「Googleアカウントでログイン」のような画面は日常的に見かけますが、その裏で動いている仕組みがOAuthです。
この記事では、OAuthの意味・動作の流れ・試験での問われ方を、IT初心者にも伝わるようにまとめました。
対象試験と出題頻度
OAuthは、基本情報技術者・応用情報技術者で出題されるテーマです。
「ユーザーのパスワードを渡さずに、外部サービスへアクセス権限を委譲する認可の仕組み」というポイントを確実に押さえておきましょう。
情報処理安全確保支援士ではH27秋期以降繰り返し出題されており、応用情報や基本情報のシラバスにも「OAuth」が明記されています。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
OAuth（オーオース）とは、一言で言うと
「ユーザーのIDやパスワードを相手に渡さずに、外部のサービスに対してリソースへのアクセス権限を委譲する認可の仕組み」
のことです。現在はバージョン2.0（OAuth 2.0）が主流で、RFC 6749として標準化されています。
イメージとしては、「ホテルのフロントで渡される部屋の鍵（カードキー）」です。
ホテルに泊まるとき、フロントで本人確認（＝認証）をした後、部屋のカードキー（＝アクセストークン）を渡されます。このカードキーがあれば、部屋のドアを開けることができます。
しかし、カードキーが使えるのは自分の部屋だけで、他の客室や従業員エリアには入れません。さらに、チェックアウトすればカードキーは無効になります。
OAuthはこの仕組みとほぼ同じです。ユーザーが「この外部サービスに、私の写真データだけ見せてOK」と許可すると、認可サーバーが外部サービスにアクセストークン（＝カードキー）を発行します。
外部サービスはユーザーのパスワードを知らなくても、トークンを使って許可された範囲のデータだけにアクセスできます。
📊 OAuthの基本情報
| 項目 | 内容 |
|---|---|
| 正式名称 | OAuth 2.0（Open Authorization 2.0） |
| 目的 | ユーザーの認証情報を渡さずに、外部サービスへリソースのアクセス権限を委譲する |
| 種別 | 認可プロトコル（認証プロトコルではない） |
| 標準仕様 | RFC 6749（IETF） |
| 身近な利用例 | 「Googleアカウントでログイン」「Facebookアカウントで新規登録」など |
解説
OAuthが登場した背景には、「パスワードを他サービスに渡す危険性」があります。
従来、WebサービスAの情報をWebサービスBで使いたい場合、ユーザーはBにAのIDとパスワードを直接入力していました。
しかし、この方法ではBにパスワードが漏えいするリスクがあり、Bが不正利用してもユーザーは止める手段がありませんでした。OAuthは「パスワードの代わりにアクセストークンを使う」という発想で、この問題を解消しました。
「認可」と「認証」の違い
OAuthを正しく理解するうえで、ここだけは確実に押さえてください。
OAuthは「認可（Authorization）」のプロトコルであり、「認証（Authentication）」のプロトコルではないという点です。
📊 認証と認可の違い
| 比較項目 | 認証（Authentication） | 認可（Authorization） |
|---|---|---|
| 意味 | 「あなたは誰か？」を確認すること | 「あなたに何を許可するか？」を決めること |
| 例え | パスポートで本人確認する | 入場チケットで入れるエリアを指定する |
| OAuthの扱い | OAuth単体では行わない | OAuthの本来の役割 |
この区別は過去問で直接正誤を問われているポイントです。
「OAuthは認証プロトコルである」は不正解、「OAuthは認可プロトコルである」が正解——この一語の違いで合否が分かれます。
OAuth 2.0の登場人物と動作の流れ
OAuth 2.0には3つの主要な登場人物がいます。それぞれの役割を整理したうえで、動作の流れを追います。
📊 OAuth 2.0の3つの登場人物
| 登場人物 | 役割 | 具体例 |
|---|---|---|
| リソースオーナー | データの持ち主であり、アクセスを許可するユーザー | あなた自身 |
| リソースサーバー （＋認可サーバー） |
保護されたデータを保持するサービス。認可サーバーを兼ねてアクセストークンを発行する | Google、Facebookなど |
| クライアント | リソースオーナーの許可を得て、リソースサーバーにアクセスする外部アプリケーション | 「Googleアカウントでログイン」するWebサービス |
動作の流れは次の通りです。
(1)ユーザー（リソースオーナー）がクライアントを利用しようとする
→ (2)クライアントがリソースサーバーへリダイレクトし、ユーザーに「この情報へのアクセスを許可しますか？」と確認
→ (3)ユーザーが許可
→ (4)リソースサーバー（認可サーバー）がクライアントへアクセストークンを発行
→ (5)クライアントはアクセストークンを使って、許可された範囲のデータにアクセス
ポイントは、この一連の流れの中でユーザーのパスワードがクライアントに渡ることは一切ないという点です。
関連プロトコルとの違い
OAuthと混同しやすいプロトコルを整理しておきます。
📊 OAuth・OpenID Connect・SAMLの比較
| プロトコル | 目的 | 扱う範囲 |
|---|---|---|
| OAuth 2.0 | リソースへのアクセス権限を委譲する | 認可のみ |
| OpenID Connect（OIDC） | OAuth 2.0をベースに「この人は誰か」も確認する | 認証＋認可 |
| SAML | 主に企業向けシングルサインオン（SSO）を実現する | 認証＋認可（XMLベース） |
基本情報・応用情報レベルでは「OAuthは認可、OpenID Connectは認証＋認可」という違いを押さえれば十分です。
SAMLはSSO（シングルサインオン）の文脈で出題されることが多いので、OAuth とは出題パターンが異なります。深追いは不要です。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 OAuthの核心を3行で
・ユーザーのパスワードを渡さずに、アクセストークンを介してリソースへの限定的なアクセス権限を委譲する仕組み
・認可（何を許可するか）のプロトコルであり、認証（誰であるか）のプロトコルではない
・認証も必要な場合はOAuth 2.0をベースにしたOpenID Connectを使う
📌 試験対策のポイント
試験では、OAuth 2.0のフロー詳細（認可コードグラント等）までは問われません。
「認可のプロトコルであること」「アクセストークンをリソースサーバー側が発行すること」「ユーザーのパスワードをクライアントに渡さないこと」の3点を答えられれば得点できます。
試験ではこう出る！
OAuthは、情報処理安全確保支援士の午前II・午後問題で繰り返し出題されているテーマです。
基本情報技術者・応用情報技術者のシラバスにも「OAuth」が明記されており（経済産業省の出題範囲資料でも言及）、今後これらの試験区分でも出題が見込まれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| 支援士 H27秋 午前II 問17 |
OAuth 2.0において、利用者Cの承認の下、WebサービスAがリソースDへの限定的なアクセス権限を取得するときの動作を問う問題。正解は「WebサービスB（リソースサーバー側）がアクセストークンを発行する」。 | ・アクセストークンの発行元はリソースサーバー側 ・デジタル証明書の送信ではない |
| 支援士 R5秋 午前II 問14 |
「OAuth 2.0に関する記述のうち、適切なものはどれか」を問う問題。正解は「認可を行うためのプロトコルであり、認可サーバが利用者の許可を得てクライアントに適切な権限を付与する」。 | ・「認可」プロトコルであり「認証」ではない ・本人確認を行う仕組みではない |
| 支援士 R3春 午後I 問1 |
OAuthを用いたソーシャルログインの実装とセキュリティに関する記述式問題。認可コードの受け渡しやアクセストークンの利用範囲が出題された。 | ・OAuthを使ったソーシャルログインの流れ ・認可コードとアクセストークンの区別 |
| 支援士 R7春 午前II 問16 |
R5秋 午前II 問14と同一の問題が再出題された。 | ・同上（再出題を確認） |
注目すべきは、午前問題では「認可か認証か」を問うパターンが鉄板だという点です。
R5秋 午前II 問14では、選択肢に「認可を行うためのプロトコル」と「認証を行うためのプロトコル」が並び、さらに「本人確認をするもの」と「適切な権限を付与するもの」が組み合わされた4択で、正確な区別が求められました。
この問題はR7春にもそのまま再出題されており、出題者が「認可と認証の混同」を狙っていることは明白です。
【頻出キーワード】
- 認可（Authorization）プロトコル
- アクセストークンの発行
- リソースオーナー、リソースサーバー、クライアント
- パスワードを渡さずに権限を委譲
- OpenID Connect（認証＋認可）との対比
試験問題で「利用者の許可を得て、クライアントに対しリソースへの適切な権限を付与する認可プロトコル」という記述があれば、それは「OAuth 2.0」です。
逆に、「アクセスしてきた者が本人であるかどうかを確認する」という記述は認証の話であり、OAuth単体の機能ではありません。
📝 IPA試験での出題パターン
午前問題では2パターンあります。
パターン1は「OAuth 2.0の説明として適切なものを選べ」形式で、「認可 vs 認証」の区別が問われます。
ひっかけ選択肢として「認証を行うためのプロトコル」「本人確認を行う仕組み」が定番です。
パターン2は「OAuth 2.0の動作として正しいものはどれか」形式で、「アクセストークンの発行元はリソースサーバー（認可サーバー）側である」が正解の鍵になります。
「クライアント側がアクセストークンを発行する」「デジタル証明書を送信する」は不正解です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. OAuth 2.0に関する記述として、最も適切なものはどれでしょうか？
- A. 認証を行うためのプロトコルであり、認可サーバーがアクセスしてきた者がリソースオーナー本人であるかどうかを確認する仕組み
- B. 認可を行うためのプロトコルであり、認可サーバーがリソースオーナーの許可を得て、クライアントに対してリソースへの適切な権限を付与する仕組み
- C. 認証と認可を同時に行うプロトコルであり、IDトークンとアクセストークンの両方を発行して、ユーザーの識別とリソースアクセスの両方を実現する仕組み
正解と解説を見る
正解：B
解説：
OAuth 2.0は認可を行うためのプロトコルであり、認可サーバーがリソースオーナー（ユーザー）の許可のもと、クライアント（外部サービス）に対してアクセストークンを発行し、リソースへの適切な権限を付与します。R5秋・R7春の支援士 午前II問題でも、この記述がそのまま正解でした。
選択肢Aは「認証を行うためのプロトコル」とありますが、OAuthは認可のプロトコルであり、本人確認（認証）は行いません。「認証」か「認可」かの一語の違いが正誤を分ける典型的なひっかけです。選択肢Cは「OpenID Connect（OIDC）」の説明です。OIDCはOAuth 2.0をベースに認証機能を追加した仕組みで、IDトークンによるユーザー識別を行います。OAuth 2.0単体では認証機能を持たない点が決定的な違いです。
よくある質問（FAQ）
Q. 「Googleアカウントでログイン」はOAuthだけで実現していますか？
厳密にはOAuthだけでは「ログイン（＝誰であるかの確認）」はできません。実際には、OAuth 2.0をベースに認証機能を追加したOpenID Connect（OIDC）が使われています。Googleが発行するIDトークンでユーザーの識別を行い、アクセストークンで必要なデータへのアクセスを認可する——この二段構えが「Googleでログイン」の実態です。
Q. アクセストークンが盗まれたらどうなりますか？
アクセストークンが漏えいすると、攻撃者がそのトークンを使ってリソースに不正アクセスできてしまいます。対策として、トークンには有効期限が設定されており、短時間で失効するよう設計されています。また、必要最小限の権限だけをトークンに付与する「スコープ」の仕組みや、通信をTLS（HTTPS）で暗号化するなどの防御策が組み合わされています。
Q. OAuth 1.0とOAuth 2.0の違いは？試験ではどちらが出ますか？
OAuth 1.0は署名ベースの認可方式で実装が複雑でした。OAuth 2.0はアクセストークンとTLSの組み合わせにより簡素化され、現在の主流です。IPA試験で問われるのはOAuth 2.0のみです。過去問でも「OAuth 2.0」と明記されて出題されているため、1.0との細かな違いを覚える必要はありません。
Q. OAuthとSAMLは何が違いますか？
OAuthは認可に特化したプロトコルで、主にWebアプリやモバイルアプリ間のAPI連携で使われます。SAMLは認証＋認可を行うXMLベースのプロトコルで、主に企業内のシングルサインオン（SSO）に使われます。試験ではOAuthは「外部サービスへの権限委譲」、SAMLは「企業内のSSO」という文脈で出題が分かれるため、この使い分けを頭に入れておくと迷いません。
