4. ID管理とアクセス制御

【図解】OAuth 2.0の仕組みとは？認可フローと4つのロールを徹底解説

2025年12月23日

「Googleアカウントでログイン」や「X（旧Twitter）連携」など、私たちが普段何気なく使っている機能の裏側には、OAuth 2.0（オーオース 2.0）という仕組みが動いています。

情報処理安全確保支援士試験（SC）において、OAuth 2.0は午後試験の最重要キーワードの一つです。特に近年では、OpenID Connect（OIDC）と絡めた設問や、スマートフォンのアプリ連携におけるセキュリティ対策（PKCEなど）が頻出しています。

しかし、「認証（Authentication）」と「認可（Authorization）」の違いや、アクセストークンとリフレッシュトークンの使い分けなど、独学でテキストを読んでいるだけではイメージしづらい部分が多いのも事実です。

本記事では、OAuth 2.0の全体像から、試験で問われる「認可コードフロー」の詳細、そしてセキュリティ上の脅威と対策までを、徹底的にわかりやすく解説します。この1記事を読み終える頃には、過去問のシーケンス図がスラスラと読み解けるようになっているはずです。

OAuth 2.0とは？「合鍵」ではなく「利用券」を渡す仕組み

OAuth 2.0を一言で表すと、「あるアプリケーションが、ユーザーに代わって、別のサービスにあるデータへアクセスする権限を与えるための標準プロトコル」です。

ここで重要なのは、「パスワード（合鍵）を渡さずに、権限（利用券)だけを渡す」という点です。

アナロジーで理解するOAuth

OAuthの仕組みは、よく「ホテルのカードキー」や「駐車場のバレーパーキング」に例えられます。

例えば、あなたが高級車（リソース）を持っていて、駐車係（クライアントアプリ）に車を預けるとします。この時、家の鍵やトランクの鍵までついた「マスターキー（IDとパスワード）」を渡してしまうと、車内の貴重品を盗まれるリスクがあります。

そこで、エンジンをかけて移動させることしかできない「バレーキー（アクセストークン）」を渡します。これなら、駐車係は駐車という目的（スコープ）だけを果たせますし、もしそのキーが悪用されても、トランクを開けられることはありません。

これがOAuth 2.0の基本的な考え方です。

  • 昔のやり方（Basic認証など）： アプリにID/パスワードを直接入力させる。「合鍵」を渡す行為。
  • OAuth 2.0： アプリに権限証（トークン）だけを渡す。「限定的な利用券」を渡す行為。

登場人物（ロール）を整理する

OAuth 2.0のフロー図（シーケンス図）を読み解くためには、登場する4つの役割（ロール）を正しく理解する必要があります。試験問題では、これらが「A社Webサーバ」「B社認証サーバ」「利用者PC」のように具体的な名称で登場しますが、脳内で以下のロールに変換して考えることが正解への近道です。

1. リソースオーナー（Resource Owner）

利用者（ユーザー）のことです。データ（リソース）の所有者であり、アプリに対して「私のデータにアクセスしてもいいよ」と許可（認可）を与える権限を持っています。

2. ユーザーエージェント（User Agent）

Webブラウザやスマートフォンのことです。ユーザーが操作するインターフェースの役割を果たします。SC試験のシーケンス図では、一番左側に描かれることが多いです。

3. クライアント（Client）

連携したいアプリケーションのことです。例えば、「写真現像アプリ」が「Googleフォト」の写真を読み込みたい場合、この「写真現像アプリ」がクライアントになります。

※ここが混同しやすいポイントですが、OAuthにおいて「クライアント」とは、ユーザーの手元にある端末ではなく、サービスを提供しているアプリ（サーバ側のWebアプリやスマホアプリそのもの）を指します。

4. 認可サーバ（Authorization Server）

IDとパスワードを管理し、トークンを発行するサーバです。GoogleやFacebook、あるいは社内の認証基盤などがこれに当たります。ユーザーが本人であることを確認（認証）し、アクセス権限（認可）を与えます。

5. リソースサーバ（Resource Server）

実際のデータ（API）を持っているサーバです。Googleフォトの写真データや、Gmailのメールデータなどが保存されている場所です。認可サーバが発行したアクセストークンを受け取り、それが正当であればデータを返します。

※GoogleやMicrosoftなどの巨大なプラットフォーマーの場合、認可サーバとリソースサーバは同じ組織によって運用されていますが、論理的には別の役割です。

最も重要な「認可コードフロー」を完全理解

OAuth 2.0にはいくつかの流れ（グラントタイプ）がありますが、情報処理安全確保支援士試験で問われるのは、セキュリティ強度が最も高く、標準的に利用される「認可コードフロー（Authorization Code Flow）」です。

このフローは、「認可コード（Authorization Code）」を受け取ってから、裏側で「アクセストークン」と交換するという2段階の手順を踏むのが特徴です。なぜこれほど面倒な手順を踏むのか？それはセキュリティを高めるためです。

ステップ1：認可リクエスト（Authorization Request）

ユーザーがクライアントアプリ（例：写真現像アプリ）にある「Googleフォトと連携する」ボタンを押します。すると、クライアントはユーザーのブラウザを、認可サーバのログイン画面へリダイレクトさせます。

この時のURLには、以下のようなパラメータが含まれています。

GET /authorize?
  response_type=code
  &client_id=CLIENT_ID
  &redirect_uri=https://client-app.com/callback
  &scope=photos.read
  &state=xyz123

各パラメータの意味は以下の通りです。

  • response_type=code： 「認可コード（code）」をください、という指定
  • client_id： クライアントアプリの識別ID。事前に認可サーバに登録しておく
  • redirect_uri： 認可が終わった後に戻ってくるURL。これも事前登録が必要（オープンリダイレクト対策）
  • scope： どのデータにアクセスしたいか（例：写真の読み取りのみ）
  • state： CSRF対策のためのランダムな文字列。試験で超頻出

ステップ2：ユーザー認証と同意（Authentication & Consent）

認可サーバの画面に切り替わります。ユーザーはここでIDとパスワードを入力してログイン（認証）します。その後、「写真現像アプリがあなたのGoogleフォトへのアクセスを求めています。許可しますか？」という同意画面が表示されます。ユーザーが「許可」ボタンを押すと、次のステップへ進みます。

ここで重要なのは、IDとパスワードは認可サーバにのみ送信され、クライアントアプリには一切知らされないということです。

ステップ3：認可コードの発行（Authorization Grant）

ユーザーが許可すると、認可サーバはブラウザを、ステップ1で指定されたredirect_uriへリダイレクトさせます。この時、URLのパラメータに「認可コード（code）」と、先ほどの「state」が付与されます。

HTTP/1.1 302 Found
Location: https://client-app.com/callback?code=AUTH_CODE_xxxxx&state=xyz123

クライアントアプリは、戻ってきたstateが最初に送ったものと一致するか確認します。一致しなければ、攻撃者による誘導の可能性があるため処理を中断します（CSRF対策）。

ステップ4：トークンの交換（Token Exchange）

ここが最重要ポイントです。クライアントアプリは、ブラウザを介さず、サーバ間の直接通信（バックチャネル）で、受け取った「認可コード」を認可サーバに送ります。この時、**「クライアントシークレット（Client Secret）」**という、クライアントアプリ専用のパスワードも一緒に送って認証を行います。

POST /token
  grant_type=authorization_code
  &code=AUTH_CODE_xxxxx
  &redirect_uri=https://client-app.com/callback
  &client_id=CLIENT_ID
  &client_secret=CLIENT_SECRET

ステップ5：アクセストークンの発行

認可サーバは、「認可コード」と「クライアントシークレット」が正しいことを確認すると、ついに「アクセストークン（Access Token）」を発行します。場合によっては「リフレッシュトークン（Refresh Token）」や、OIDCの場合は「IDトークン」も一緒に返却されます。

なぜ「認可コード」を挟むのか？

「最初からステップ3でアクセストークンを返せばいいのでは？」と思うかもしれません。これをやっていたのが、以前使われていた（現在は非推奨の）「インプリシットフロー（Implicit Flow）」です。

ブラウザのURLバー（リダイレクト先）にアクセストークンを含めると、ブラウザの履歴に残ったり、Refererヘッダを通じて外部に漏洩したりするリスクがあります。認可コードフローでは、URLに乗るのは一時的な「認可コード」だけです。本物の鍵である「アクセストークン」は、ブラウザからは見えないサーバ間の直接通信で受け渡されるため、非常に安全性が高いのです。

トークンの種類と管理：アクセストークン vs リフレッシュトークン

OAuth 2.0で扱われるトークンには、大きく分けて2種類あります。試験ではこの違いやライフサイクル（有効期限）の管理が問われます。

アクセストークン（Access Token）

リソースサーバ（API）へのアクセスパスポートです。「有効期限」と「スコープ（権限範囲）」が含まれています。

  • 有効期限： 短い（数分〜1時間程度）
  • 用途： データを取得するたびにAPIリクエストのヘッダに付与して送信する
  • 形式： ランダムな文字列、またはJWT（JSON Web Token）形式

リフレッシュトークン（Refresh Token）

アクセストークンを再発行するための特別なチケットです。

  • 有効期限： 長い（数日〜数ヶ月、あるいは無期限）
  • 用途： アクセストークンの有効期限が切れた際、ユーザーに再度ログイン操作をさせずに、新しいアクセストークンを取得するために使う
  • 重要性： これが漏れると永続的にアクセス権を奪われるため、アクセストークン以上に厳重な管理が必要

試験で頻出！PKCE（ピクシー）対策とは？

スマートフォンアプリ（ネイティブアプリ）やSPA（Single Page Application）の場合、先ほどの「クライアントシークレット」を安全に保管することができません（アプリのコード内に埋め込むと、解析されて盗まれるリスクがあるため）。

そこで登場するのが、PKCE（Proof Key for Code Exchange：ピクシー）です。近年のSC試験では、「アプリ連携におけるセキュリティ対策」としてPKCEの仕組みが問われることがあります。

PKCEの仕組み：ワンタイムパスワードのようなもの

PKCEは以下の手順で動作します。

  1. リクエスト時： クライアントは、ランダムな文字列（code_verifier）を生成し、それをハッシュ化した値（code_challenge）を認可リクエストに含めて送ります。「後で答え合わせをするから、このハッシュ値を覚えておいてね」という宣言です。
  2. トークン交換時： クライアントは、認可コードを送信する際、ハッシュ化する前の元の文字列（code_verifier）を一緒に送ります。
  3. 検証： 認可サーバは、送られてきたcode_verifierをハッシュ化し、最初に受け取ったcode_challengeと一致するか確認します。

これにより、もし途中で「認可コード」が攻撃者に盗まれたとしても、攻撃者は元のcode_verifierを知らないため、アクセストークンへの交換ができなくなります。「認可コード横取り攻撃」への決定的な対策となります。

支援士試験で問われるセキュリティリスクと対策まとめ

OAuth 2.0の実装や運用において、どのような脆弱性が狙われるのか。試験対策として以下の3点を必ず押さえておきましょう。

1. CSRF（クロスサイトリクエストフォージェリ）

  • 攻撃手法： 攻撃者が用意した自分のアカウントとの連携処理を、被害者に踏ませることで、被害者のアプリを攻撃者のアカウントと紐付けてしまう攻撃（ソーシャルログイン時などに発生）
  • 対策： stateパラメータを使用する。リクエスト時に推測困難なランダム値を生成し、レスポンス時に検証することで、リクエストとレスポンスの整合性を確認する

2. オープンリダイレクト

  • 攻撃手法： redirect_uriパラメータを改ざんし、認可コードやトークンを攻撃者のサイトへ転送させる
  • 対策： 認可サーバ側で、事前に登録されたredirect_uriと完全一致するかを検証する（部分一致はNG）

3. リソースオーナーのパスワードクレデンシャルグラントの禁止

  • 内容： 以前は「Resource Owner Password Credentials Grant」という、アプリに直接ID/パスワードを入力させてトークンを取得する方法がありました
  • リスク： パスワード漏洩のリスクが高く、OAuthの理念に反するため、現在のRFC（OAuth 2.1など）では**完全に非推奨（削除予定）**となっています。試験でも「使ってはいけない」という文脈で出ることがあります

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

試験勉強をしていると、必ずと言っていいほど「OAuthとOIDCって何が違うの？」という疑問にぶつかります。ここで改めて技術的な視点から深掘りしておきます。

目的の違い

  • OAuth 2.0： 「認可（Authorization）」が目的。例：「私のGoogleドライブにファイルを保存することを許可する」
  • OpenID Connect： 「認証（Authentication）」が目的。OAuth 2.0を拡張して作られた。例：「あなたは誰ですか？（IDカードの提示）」

トークンの違い

OAuth 2.0で発行されるのはアクセストークンです。これは「鍵」の機能しか持たず、通常は中身を見ても「誰の鍵か」というユーザー情報は（標準仕様としては）含まれていません。あくまで「APIを叩くためのチケット」です。

一方、OIDCで追加されるのはIDトークンです。これはJWT（JSON Web Token）という形式で厳密に仕様化されており、中身をデコードすると以下のようなユーザー情報（クレーム）が入っています。

{
  "iss": "https://accounts.google.com",  // 発行者
  "sub": "1234567890",                   // ユーザーID（Subject）
  "aud": "my-client-app-id",             // 宛先（クライアントID）
  "iat": 1616161616,                     // 発行日時
  "exp": 1616165216                      // 有効期限
}

試験で「IDトークンの検証手順を答えよ」という問題が出た場合、以下のチェックポイントを記述する必要があります。

  1. 署名の検証： 認可サーバの公開鍵を使って、IDトークンが改ざんされていないか確認する
  2. iss（発行者）の確認： 信頼する認可サーバから発行されたものか
  3. aud（オーディエンス）の確認： 間違いなく自システム（自分のクライアントID）宛に発行されたものか
  4. exp（有効期限）の確認： 期限切れでないか
  5. nonce（ノンス）の確認： リプレイ攻撃対策として、リクエスト時に送ったnonce値と一致するか

OAuth 2.0単体では、あくまで「APIアクセスの許可」であり、ユーザー認証（ログイン）に使うのは本来の用途ではありません（Pseudo-Authenticationと呼ばれるアンチパターン）。これを標準化し、安全に認証に使えるようにしたのがOIDCです。

OAuth 2.0のスコープ（Scope）設計の重要性

セキュリティの原則に「最小権限の原則」があります。OAuth 2.0においてこれを実現するのがスコープ（Scope）です。

開発者や設計者としてOAuthを利用する場合、漫然と「全権限」を要求してはいけません。例えば、ただ「ユーザーのプロフィール画像を表示したい」だけのアプリが、contacts.read（連絡先の読み取り）やdrive.file（ファイルの操作）といったスコープを要求するのは過剰であり、危険です。

試験の午後問題では、セキュリティインシデントの事例として、「悪意あるアプリが不必要な権限（スコープ）を要求し、ユーザーが誤って許可してしまったことで情報が漏洩した」というシナリオが登場します。対策としては、「アプリケーションが必要とする最小限のスコープのみを定義し、ユーザーに認可を求めること」が正解となります。

トークンの無効化（Revocation）とイントロスペクション

アクセストークンやリフレッシュトークンが万が一流出した場合、どうすればよいでしょうか？OAuth 2.0には、トークンを無効化するための仕組みも定義されています。

RFC 7009（Token Revocation）

クライアントが認可サーバに対して、「このトークンはもう使わない（または流出した）ので無効にしてくれ」と依頼するエンドポイントです。ログアウト処理の実装時によく使われます。

RFC 7662（Token Introspection）

リソースサーバ（API側）が、送られてきたアクセストークンが現在も有効かどうかを認可サーバに問い合わせるための仕組みです。JWTのような自己完結型のトークンであれば署名検証だけで済みますが、ランダム文字列型のトークンの場合、このイントロスペクションを使ってリアルタイムに有効性を確認する必要があります。

試験では、「APIゲートウェイにおいてアクセストークンの有効性をどう確認するか」といった設計・実装寄りの設問で、これらの知識が問われる可能性があります。

今後のOAuth：OAuth 2.1への動き

現在、IETFではOAuth 2.0のセキュリティベストプラクティスを取り込み、仕様を整理したOAuth 2.1の策定が進んでいます。SC試験は最新のトレンドも反映されるため、この動きも知っておくと有利です。

OAuth 2.1での主な変更点は以下の通りです（セキュリティ強化の方向性）。

  1. PKCEの必須化： 認可コードフローを使用するすべてのクライアントでPKCEが必須となる
  2. インプリシットフローの廃止： アクセストークンをブラウザに直接返すフローは仕様から削除される
  3. リソースオーナーパスワードクレデンシャルグラントの廃止： パスワードを直接扱うフローは削除される

これらはつまり、「今までのSC試験で『セキュリティ上の弱点』とされていた部分が、仕様レベルで塞がれる」ということです。今のうちから「なぜ廃止されるのか」を理解しておくことは、現行のOAuth 2.0の弱点を深く理解することと同義であり、試験対策として非常に有効です。

OAuth 2.0実装時のセキュリティチェックリスト

情報処理安全確保支援士として、OAuth 2.0を実装・評価する立場になった際に確認すべきポイントをまとめます。

認可サーバ側

  • redirect_uriの完全一致検証が実装されているか
  • stateパラメータの検証が必須となっているか
  • トークンの有効期限が適切に設定されているか（アクセストークン：短、リフレッシュトークン：長）
  • クライアント認証（Client Secret）が適切に管理されているか
  • PKCEのサポートが実装されているか

クライアントアプリ側

  • トークンを安全な場所に保管しているか（ローカルストレージではなくHttpOnly Cookieなど）
  • stateパラメータを毎回ランダム生成し、検証しているか
  • 必要最小限のスコープのみを要求しているか
  • トークンの有効期限切れ時の処理が実装されているか
  • PKCEを使用しているか（特にネイティブアプリ、SPA）

OAuth 2.0のよくある誤解と落とし穴

ここでは、学習者が陥りやすい誤解や、実装時に見落としがちなポイントを解説します。

誤解1：「OAuthはログイン機能である」

OAuth 2.0は**認可（Authorization）の仕組みであり、本来は認証（Authentication）**のためのものではありません。「Googleアカウントでログイン」と表示されていても、その裏側では実際にはOpenID Connect（OIDC）が動いています。

純粋なOAuth 2.0だけでログインを実装しようとすると、アクセストークンを取得した後、「このトークンは誰のものか？」を確認するために別途APIを呼び出す必要があります。この方法は「Pseudo-Authentication（疑似認証）」と呼ばれ、セキュリティリスクがあるため推奨されていません。

誤解2：「アクセストークンは一度取得すれば永久に使える」

アクセストークンには必ず有効期限があります。有効期限が切れた後は、リフレッシュトークンを使って新しいアクセストークンを取得する必要があります。この仕組みを理解していないと、「最初は動いていたのに、しばらくすると動かなくなる」という問題に直面します。

誤解3：「クライアントシークレットは暗号化すれば安全」

ネイティブアプリやSPAにおいて、クライアントシークレットをアプリ内に埋め込む行為は、たとえ暗号化していても安全ではありません。リバースエンジニアリングによって復号化される可能性があるためです。このような環境では、クライアントシークレットに頼らず、PKCEを使用する必要があります。

OAuth 2.0のグラントタイプ全種類

試験では認可コードフローが中心ですが、他のグラントタイプについても概要を知っておくと理解が深まります。

1. 認可コードフロー（Authorization Code Grant）

本記事で詳しく解説した、最も安全なフロー。Webアプリケーションで標準的に使用される。

2. インプリシットフロー（Implicit Grant）

ブラウザのリダイレクトで直接アクセストークンを返すフロー。OAuth 2.1では廃止予定。セキュリティリスクが高いため、現在は使用すべきではない。

3. リソースオーナーパスワードクレデンシャルグラント（Resource Owner Password Credentials Grant）

ユーザーがクライアントアプリに直接IDとパスワードを入力するフロー。OAuthの理念に反するため、OAuth 2.1では廃止予定。レガシーシステムの移行期のみ使用が許容される。

4. クライアントクレデンシャルグラント（Client Credentials Grant）

ユーザーではなく、アプリケーション自身がリソースにアクセスする場合に使用。例：サーバー間通信、バッチ処理など。ユーザーの代理ではなく、アプリ自身の権限でAPIを呼び出す。

5. デバイスフロー（Device Authorization Grant）

スマートTVやIoTデバイスなど、ブラウザが使えない環境でOAuthを実現するためのフロー。デバイスにコードを表示し、ユーザーがスマホやPCで認可する仕組み。

実際の攻撃シナリオから学ぶ

情報処理安全確保支援士として、攻撃者の視点を理解することは重要です。ここでは、OAuth 2.0に関する代表的な攻撃シナリオを紹介します。

シナリオ1：認可コード横取り攻撃

攻撃手法： 攻撃者が用意した悪意あるアプリが、正規のアプリのredirect_uriに似たURLを登録します。ユーザーが正規アプリと連携しようとした際、攻撃者はネットワーク上で認可コードを盗聴し、自分のアプリでトークンと交換します。

対策： PKCEを実装することで、認可コードを盗まれてもcode_verifierがなければトークンを取得できなくなります。

シナリオ2：トークンリプレイ攻撃

攻撃手法： 盗聴したアクセストークンを使い回して、不正にAPIにアクセスします。

対策： アクセストークンの有効期限を短くする。HTTPS通信を必須とする。可能であればトークンをワンタイム使用に限定する。

シナリオ3：フィッシングによる同意の誘導

攻撃手法： 攻撃者が正規サービスに似せたフィッシングサイトを作成し、ユーザーに悪意あるアプリとの連携を承諾させます。

対策： ユーザー教育。同意画面で要求されているスコープを必ず確認する習慣をつける。認可サーバ側では、不審なクライアントの登録を審査する。

OAuth 2.0の実装フレームワークとライブラリ

実際の開発では、OAuth 2.0をゼロから実装することはほとんどありません。信頼性の高いライブラリを使用することで、セキュリティリスクを大幅に軽減できます。

認可サーバ側

  • Keycloak： オープンソースのアイデンティティ・アクセス管理ソリューション
  • Auth0： クラウドベースの認証・認可プラットフォーム
  • Okta： エンタープライズ向けアイデンティティ管理サービス
  • Spring Authorization Server： Spring Frameworkベースの認可サーバ実装

クライアント側

  • Passport.js（Node.js）： OAuth/OIDC対応の認証ミドルウェア
  • Spring Security OAuth（Java）： Spring BootでのOAuth実装
  • Authlib（Python）： PythonのOAuth/OIDCライブラリ
  • AppAuth（iOS/Android）： ネイティブアプリ向けのOAuth SDKs

これらのライブラリは、PKCEやstate検証など、セキュリティのベストプラクティスを標準で実装しています。

情報処理安全確保支援士としての視点

試験に合格し、支援士として登録された後は、組織のセキュリティアドバイザーとしての役割が求められます。OAuth 2.0に関して、支援士が提供すべき助言をまとめます。

システム設計レビュー時のチェックポイント

  1. 適切なグラントタイプの選択： システムの特性に応じた最適なフローが選択されているか
  2. トークンのライフサイクル管理： 有効期限、更新、無効化の仕組みが適切に設計されているか
  3. スコープの粒度： 過剰な権限付与を防ぐための適切なスコープ設計がされているか
  4. 監査ログ： 認可の履歴、トークン発行の記録が適切に保存されているか

インシデント対応

OAuth 2.0関連のインシデントが発生した場合、支援士は以下の対応を指揮する必要があります。

  1. 影響範囲の特定： 漏洩したトークンの権限範囲、影響を受けるユーザー数の把握
  2. 即時対応： 該当トークンの無効化、認可の取り消し
  3. 根本原因の分析： 脆弱性の特定、攻撃経路の解明
  4. 再発防止策： PKCEの導入、redirect_uri検証の強化など

次世代の認証・認可技術へ

OAuth 2.0は現在の標準ですが、技術は常に進化しています。支援士として、今後の動向にも注目しておく必要があります。

FIDO2/WebAuthn

パスワードレス認証の標準規格。OAuth 2.0と組み合わせることで、よりセキュアな認証を実現できます。生体認証やセキュリティキーを使用し、フィッシング耐性が高いのが特徴です。

ゼロトラスト・アーキテクチャ

「境界防御」から「常に検証」への転換。OAuth 2.0のアクセストークンは、ゼロトラストモデルにおける「継続的な認可」の実現に重要な役割を果たします。

Decentralized Identity（分散型ID）

ブロックチェーン技術を活用し、ユーザー自身がアイデンティティ情報を管理する新しいアプローチ。OAuth 2.0との統合も研究されています。

学習を継続するためのリソース

OAuth 2.0の理解をさらに深めるために、以下のリソースを活用することをお勧めします。

公式仕様書

  • RFC 6749： OAuth 2.0の基本仕様
  • RFC 7636： PKCE（ピクシー）の仕様
  • RFC 8252： ネイティブアプリでのOAuth 2.0のベストプラクティス

学習サイト

  • OAuth.net： OAuth 2.0の公式情報サイト
  • jwt.io： JWTのデバッグ・学習ツール
  • IPA情報処理推進機構： セキュリティ関連の技術文書

ハンズオン環境

実際に手を動かして学ぶことで、理解が格段に深まります。OAuth 2.0のプレイグラウンド環境を利用して、認可フローを体験してみましょう。

最終チェック：試験直前の確認事項

情報処理安全確保支援士試験の直前に、以下の項目を最終確認してください。

  • [ ] OAuth 2.0の4つのロールを説明できる
  • [ ] 認可コードフローのシーケンス図を描ける
  • [ ] stateパラメータの目的（CSRF対策）を説明できる
  • [ ] PKCEの仕組みと必要性を説明できる
  • [ ] アクセストークンとリフレッシュトークンの違いを説明できる
  • [ ] OAuth 2.0とOIDCの違いを説明できる
  • [ ] redirect_uriの検証方法を説明できる
  • [ ] 非推奨のグラントタイプ（インプリシット、パスワード）とその理由を説明できる
  • [ ] スコープの最小権限の原則を適用できる
  • [ ] IDトークンの検証手順を列挙できる

3分で解ける！OAuth 2.0 復習クイズ

「なんとなく分かったつもり」になっていませんか？記事の内容をしっかり理解できているか、サクッと練習問題で確認してみましょう。もし間違えても、解説に戻れば大丈夫です！

【演習】OAuth 2.0 理解度チェック（全10問）

まとめ：OAuth 2.0は「信頼の連鎖」をセキュアに作る技術

今回の記事では、OAuth 2.0の仕組みについて、基本的な概念から試験レベルの技術詳細までを解説しました。

重要なポイントを振り返ります。

  • OAuth 2.0は「認可」の仕組み（鍵そのものではなく、利用券を渡す）
  • 4つのロール（リソースオーナー、UA、クライアント、認可サーバ）の関係性を理解する
  • 認可コードフローは、フロント（ブラウザ）とバック（サーバ間通信）を使い分けることで安全性を担保している
  • stateパラメータはCSRF対策、PKCEは認可コード横取り対策として必須
  • OAuth 2.0とOIDCの違いを明確に理解する（認可 vs 認証）
  • スコープは最小権限の原則に基づいて設計する
  • OAuth 2.1では、セキュリティ強化のため多くの脆弱なフローが廃止される予定

SC試験の午後問題では、数十ページにわたる長文の中に、こうしたOAuthのシーケンス図がポンと置かれ、「図中のパラメータaに入る適切な値を答えよ」や「この通信を行うセキュリティ上の理由は何か」といった設問が出されます。

今回解説した「なぜそのパラメータが必要なのか」「なぜその通信経路を使うのか」という「理由」の部分をしっかり理解していれば、どんな変化球の問題が来ても怖くありません。

OAuth 2.0はWebセキュリティの要（かなめ）です。この知識は試験合格だけでなく、実際の開発現場やシステム設計でも必ず役に立ちます。しっかりと復習して、自分のものにしておきましょう。

これらの項目すべてにチェックが入れば、OAuth 2.0に関する午後問題は十分に対応できるはずです。

次回は、情報セキュリティの基礎にして奥義、「アクセス制御モデル（DAC, MAC, RBAC）の違い」について解説します。「社長は見れるけど課長は見れない」「機密レベルの高いファイルへの書き込み禁止」など、システムを守るための権限管理の考え方を整理していきます。お楽しみに！

-4. ID管理とアクセス制御