はじめに

備忘録です。OAuth / OIDC 周りの技術について自分なりにまとめてみました。

改訂履歴

• 2026/05/29 : 初版公開。

本文

1. OAuth とは

OAuth (オーオース) とは、権限の認可 (Authorization) を行うための仕組み（プロトコル）です。サードパーティ製のアプリケーションに対して、ユーザーのパスワードを教えることなく、特定のデータや機能へのアクセス権を安全に委譲（受け渡し）することができます。

2026 年現在、最新の安定版は OAuth 2.0 です。

また、よりセキュリティを厳格化した OAuth 2.1 の仕様策定も進んでいます。

2. 認証と認可の違い

以下の記事が分かりやすく、参考になります。

また OAuth を認証に流用した際、発生するセキュリティ上の問題については、以下の記事が参考になります。

3. OAuth 2.0 認可フロー

3-1. 認可フロー (Authorization Code Grant)

OAuth 2.0 で定義されている認可フロー (OAuth Grant Types) には、いくつかの種類があります。

今回は最もポピュラーな認可フローである Authorization Code Grant を見ていきます。

① 事前準備

まず前提として、OAuth を利用するクライアント（ウェブサービス）は事前に、認可サーバーのデベロッパーサイトなどから登録を行い、以下の情報を取得・設定しておく必要があります。

認可サーバーに事前登録する項目

• redirect_uri ... 認可後に認可コードを受け取るための、クライアント自身の URL。セキュリティのため、完全一致が求められます。

認可サーバーから発行され、クライアント側で保持する項目

• client_id ... 認可サーバーから発行された、クライアントを識別するための公開 ID。
• client_secret ... 認可サーバーから発行された秘密鍵。

② 認可フローのシーケンス

3-2. 用語解説

① ユーザー (Resource Owner)

サービスを利用するユーザー（リソースの所有者）です。

② クライアント (Client)

ユーザーの代わりに、他のサービスにリソースを要求するアプリケーションです。

③ 認可サーバー (Authorization Server)

ユーザーの認可（同意）を得てクライアントのリクエストを検証し、アクセストークンを発行するサーバーです。例えば Google アカウントのデータと連携したい場合は、Google が提供する認可サーバーにリクエストを送信します。

④ リソースサーバー (Resource Server)

実際にユーザーのデータ（リソース）を持っているサーバーです。例えば Google の場合、ユーザーのファイルやメールを管理している Google Drive API や Gmail API などの各 API サーバーがこれに該当します。

3-3. 認可コード横取り攻撃と PKCE

上記の Authorization Code Grant は、従来のサーバーサイド MVC アプリや Web API では安全に機能していましたが、後述する特定の環境においてはセキュリティ上の脆弱性がありました。それを解決するために導入されたのが PKCE (Proof Key for Code Exchange / ピクシー) という拡張仕様です。

① 認可コード横取り攻撃

OAuth では、アプリケーションが動く環境によってクライアントを 2 つに分類します。

• コンフィデンシャルクライアント ... 従来のサーバーサイド MVC アプリや Web API など「Web サーバー側で動くアプリ」です。秘密鍵 (client_secret) をWeb サーバー内部に、安全に隠し持つことができます。
• パブリッククライアント ... スマートフォン向けのネイティブアプリやデスクトップアプリ、JavaScript のみで動作する SPA (Single Page Application) など「ユーザーの端末（手元）にプログラムを丸ごとダウンロードして動かす」仕組みのアプリです。ソースコードが端末内で事実上の公開状態にあり、秘密鍵 (client_secret) を安全に隠し持つことができません。

認可サーバーは、相手のタイプを識別して処理を変えています。相手がパブリッククライアントである場合、秘密鍵を持てない性質を考慮し【アクセストークン要求】時に秘密鍵 (client_secret) の検証を行わずに、認可コードの合致だけでトークンを発行します。

しかしこの場合、以下のシナリオで「認可コード横取り攻撃」が成立してしまいます。

1. 認可サーバーから正規のアプリへ「認可コード」がリダイレクトで返却される。
2. 悪意ある別のアプリによって、何らかの手段で認可コードが横取りされる。
3. 攻撃者は、横取りした認可コードを認可サーバーに送りつける。
4. 認可サーバーは、認可コードの正当性だけで攻撃者にアクセストークンを不正発行してしまう。

つまり「秘密鍵の検証がないパブリッククライアントでは、認可コードさえ手に入れば誰でもアクセストークンを発行できてしまう」という致命的な隙がありました。

② PKCE による解決策

PKCE (Proof Key for Code Exchange / ピクシー) とは、固定の秘密鍵（client_secret）の漏洩リスクを補うために「その場の通信でのみ有効な、一度限りの使い捨てパスワード」を動的に生成して検証する仕組みです。PKCE は拡張仕様 RFC 7636 で定義されています。

PKCE での【認可要求】時、クライアント（ウェブサービス）は client_id などのパラメーターと一緒に、ランダムな文字列 (code_verifier) のハッシュ値 (code_challenge) と、そのハッシュ化方式 (code_challenge_method) を送ります。

そして【アクセストークン要求】時に元の文字列 (code_verifier) を答え合わせとして送ることで、認可サーバー側で【認可要求】と【アクセストークン要求】が同じアプリであることを検証できます。これにより、仮に認可コードだけを横取りされても、アクセストークンを引き換えられなくなります。

3-4. CSRF 攻撃と state パラメーター

OAuth 2.0 には CSRF 攻撃を受ける可能性もあります。その対策として state パラメーターの利用が推奨されています。

① CSRF 攻撃

OAuth における CSRF 攻撃は、一般的な「勝手に書き込みされる」攻撃とは異なり「被害者のアカウントに攻撃者の識別子（アカウント）を紐付けさせる」という情報窃取の手口です。

1. 攻撃者は【認可コード返却】の直前まで自分で処理を進め、発行された「攻撃者の認可コード」をコピーして処理をストップする。
2. 攻撃者はコピーした認可コードを含む、クライアント（ウェブサービス）へのリダイレクト URL を作成し、メールや SNS などで被害者に踏ませる。
3. 罠 URL を踏まされた被害者のブラウザは、被害者がログイン中のクライアント（ウェブサービス）に対して「攻撃者の認可コード」を送りつけてしまう。
4. クライアント（ウェブサービス）側は、それを被害者自身の正常なリクエストと誤認し、その認可コードを使って【アクセストークン要求】を行う。
5. 結果として、被害者のログインセッションに対して、攻撃者のアカウント情報が連携されてしまう。これにより、攻撃者は被害者のデータにアクセスできる。

② state パラメーター

この攻撃を防ぐため、クライアント（ウェブサービス）は【認可要求】時に、推測困難な値である state を生成し、client_id などのパラメーターと一緒に送信します。それと同時に Cookie など自身のセッションにも state を保存しておきます。

認可サーバーは【認可コード返却】時、受け取った state の値をそのまま送り返します。クライアント（ウェブサービス）は、戻ってきた state と、自分がセッションに保存していた state が一致するかを検証します。

攻撃者が用意した罠 URL には、被害者のセッションに対応する正しい state を含めることができないため、検証エラーとなり攻撃を未然に防ぐことができます。

4. OIDC (OpenID Connect) とは

OIDC (OpenID Connect) とは、OAuth 2.0 のフレームワークをベースに拡張された、認証 (Authentication) のためのプロトコルです。OAuth 2.0 が認可のための仕組みであったのに対し、OIDC は認証を安全に証明するために作られました。

OIDC は OpenID Foundation が管理運営しています。

2014 年に標準仕様として公開されて以来、2026 年現在も OpenID Connect Core 1.0 が最新のベース仕様として広く普及し、利用され続けています。

5. OIDC (OpenID Connect) 認証フロー

OIDC の基本的なフロー (Authorization Code Flow) は OAuth 2.0 の Authorization Code Grant とほぼ同じです。主な違いは以下の点にあります。

1. scope パラメーターに openid を指定する ... 【認可要求】を送る際 scope=openid を含めることで、認可サーバーに対して「これは OAuth ではなく OIDC のリクエストである」と明示します。
2. ID トークンが返却される ... 認証・認可が完了すると、アクセストークンと同時に ID トークンがクライアント（ウェブサービス）に返却されます。
3. UserInfo エンドポイントの存在 ... 必要に応じて、アクセストークンを使って UserInfo エンドポイントという API を叩くことで、ユーザーのプロフィール情報を取得できます。

おわりに

想像以上に複雑で大変でした。