先に読むと理解しやすい記事：認証・認可 / トークン・APIキー・Bearer認証 / JWT
権限を渡す仕組みとログインを区別する
OAuth 2.0は、あるサービスの情報や操作を、別のアプリへ限定して許可するための枠組みです。たとえば印刷アプリへ写真サービスの読み取りを許可し、写真サービスのパスワード自体は印刷アプリへ渡さずに済むようにします。
OpenID Connectは、OAuth 2.0の上で利用者の認証結果を伝える仕組みです。略称はOIDCです。「外部アカウントでログインする」アプリは、受け取ったIDトークンを検証して、認証された利用者を特定できます。OAuthのアクセストークンを受け取っただけで、任意のログイン用途に使えるとは限りません。
利用者・アプリ・認可サーバー・APIが登場する
利用者は、写真などのデータへのアクセスを許す人です。クライアントは、その許可を受けて動く印刷アプリです。認可サーバーは、利用者の認証や許可の処理を行ってトークンを発行します。リソースサーバーは、写真を提供するAPIです。
認可サーバーと写真APIは同じ事業者の別機能の場合もあります。client_idは登録したアプリの識別子で、秘密のパスワードとは異なります。サーバーで保持できるclient_secretを使う構成もありますが、公開配布するブラウザコードの中へ隠せません。
参照：出典 s1
認可コードを受け取り、トークンへ交換する
代表的な認可コードフローでは、印刷アプリが利用者のブラウザを認可サーバーへ移動させます。要求にはアプリの識別子、求める権限を表すスコープ、処理後の戻り先であるredirect_uriなどを含めます。
認可サーバーは利用者を認証し、必要な許可を確認した後、登録された戻り先へ認可コードを返します。アプリはコードを認可サーバーのトークン取得先へ送り、アクセストークンなどへ交換します。コードは短時間の交換用の値で、写真APIへ提示する値とは別です。
次の図はサーバーを持つアプリの説明です。アプリはアクセストークンを写真APIへ送り、APIが許可範囲を検証して写真を返します。利用者のブラウザを経由する処理と、アプリのサーバーから送る処理を区別します。
- ブラウザ：印刷アプリから認可サーバーへ移動
- 認可サーバー：利用者を認証し、許可を確認
- ブラウザ：登録された戻り先へ認可コードを送る
- 印刷アプリのサーバー：コードをトークンへ交換
- 印刷アプリのサーバー：アクセストークンで写真APIを呼ぶ
参照：出典 s1
アクセストークンとIDトークンは利用先が違う
アクセストークンはAPIへ提示し、許可されたデータや操作を利用するための値です。形式は必ずしもJWTではありません。リフレッシュトークンは、新しいアクセストークンを得るために認可サーバーへ提示する値で、発行されない構成もあります。
IDトークンは認証結果をクライアントへ伝えるJWTです。クライアントは署名、発行者、自分が受信先か、有効期限などを検証します。API用のアクセストークンと置き換えて使いません。OIDCではopenidスコープを指定して認証を要求します。
PKCE・state・nonceで通信を結び付ける
PKCEは、コードを要求したアプリと、コードをトークンへ交換するアプリを結び付ける仕組みです。アプリはランダムなcode_verifierを保持し、その変換値code_challengeを最初に送ります。交換時にverifierを提示し、認可サーバーが対応を確認します。通常はS256というSHA-256を使う方式を選びます。
stateは、戻ってきた応答を開始したブラウザの処理に結び付けるためなどに使う値です。nonceはOIDCの要求とIDトークンを結び付ける値で、送った場合は返された値を確認します。役割が違うため、単に乱数を一つ付ければすべて解決するとは考えません。
戻り先や応答の結び付けが欠けると乗っ取られる
仮定の例として、認可サーバーが任意のredirect_uriを受け付けるとします。攻撃者が自分の受信先を指定した認可URLを被害者へ開かせ、許可を進めさせると、コードが攻撃者へ届くおそれがあります。他の交換条件まで満たすと、攻撃者がトークンを取得できます。
戻り先は登録済みの値と厳密に照合し、PKCEなどで交換を結び付けます。アプリ側でも開始した処理との対応とIDトークンを検証します。スコープは必要な範囲へ絞り、維持されている認証ライブラリーを使ってプロトコル全体を実装します。
ログインとAPI連携のどちらかを明確にする
確認問題：写真一覧の読み取り用アクセストークンを受け取ったら、それをどのサービスのログイン証明にも使えるでしょうか。答えは使えません。利用先、意味、発行条件が用途ごとに異なります。
設計時には、誰がトークンを受け取り、どこで検証し、どのアカウントへ対応付けるかを図にします。OIDCの利用者は、発行者を示すissと主体を示すsubの組など、仕様に基づく識別で扱います。表示名だけで別アカウントを統合しません。
出典・確認範囲
- [s1] The OAuth 2.0 Authorization FrameworkIETF / RFC 6749 / 確認日 2026-11-03
- [s2] OpenID Connect Core 1.0 incorporating errata set 2OpenID Foundation / 確認日 2026-11-03
- [s3] Best Current Practice for OAuth 2.0 SecurityIETF / RFC 9700 / 確認日 2026-11-03
- [s4] Proof Key for Code Exchange by OAuth Public ClientsIETF / RFC 7636 / 確認日 2026-11-03
通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。