OAuth 2.0認可アクセストークンPKCEOIDCAPISSO認証

IDENTITY / AUTHORIZATION / API SECURITY

OAuth 2.0とは？
認可・トークン・PKCEを体系的に理解する

公開日：2026-10-10

「予定管理アプリがあなたのGoogleカレンダーへのアクセスを求めています」。この許可画面の裏では、パスワードを他社アプリに預けず、許可した範囲だけAPIへのアクセスを委任する仕組みが動いています。

この記事の学習ルート

身近な連携画面 → 認証と認可 → OAuthの4役 → ノード式通信図 → 認可コードとPKCE → トークンとScope → OIDC・SAMLとの違い → セキュリティ対策 → 操作ラボ。

1. 身近な「連携を許可しますか？」は何をしている？

予定を自動集計するアプリがGoogleカレンダーの予定を読み取る場合を考えましょう。以前ならGoogleのパスワードをそのアプリに教える、という危険な設計になりがちでした。OAuth 2.0では、利用者がGoogle側で許可すると、アプリに限定的なAPIアクセス権を付与できます。

生活・仕事の例	連携したい情報	気を付けたいこと
Googleカレンダーと予定管理アプリ	カレンダーの予定を読み込む、必要なら編集する	閲覧のみで足りるなら書き込み権限を要求しない
GitHubと開発ツール	リポジトリの情報を参照する	広いリポジトリ権限を与えず必要な範囲に限定する
Google Driveと文書編集ツール	利用者が選んだファイルの読み取りや更新	アプリが必要とするファイル・操作だけを確認する
Microsoftの業務アプリ連携	Microsoft GraphなどのAPIにアクセス	個人の同意と組織管理者の同意は別のポリシーがあり得る
Googleでログイン	Google側でユーザー認証を行う	これは通常OIDCによるログイン機能。API認可だけのOAuthと区別

2. 認証・認可・委任は別物

概念	確かめること	身近な例
認証（Authentication）	あなたは誰か	Googleアカウントへパスキーでログインする
認可（Authorization）	何をしてよいか	カレンダーは読めるが削除はできない
委任（Delegation）	その権限を別アプリに行使させる	予定管理アプリが代わりにカレンダーAPIを呼ぶ

OAuth 2.0はアクセス権限を委任するためのフレームワークです。認可時に利用者をログインさせることは多いものの、OAuthのアクセストークンを受け取っただけで「誰がログインしたか」を標準的な方法で証明するわけではありません。ログイン用の標準的な仕組みはOpenID Connect（OIDC）が補います。

3. 4つの役割を覚える：誰がトークンを発行する？

正式名称・意味	担当する役割	カレンダーの例
Resource Owner（リソースオーナー）	保護された情報へのアクセスを許可できる主体	カレンダーの持ち主である利用者
Client（クライアント）	他者のAPIへアクセスしたいアプリ	外部の予定管理アプリ
Authorization Server（認可サーバー）	許可の処理・アクセストークン発行	Googleの認可サービス
Resource Server（リソースサーバー）	アクセストークンを検証してAPIの情報を返す	Google Calendar API

ノード式：利用者・外部アプリ・Googleの役割

利用者（情報の持ち主）

外部の予定管理アプリ（Client）

Google（認可サーバー＋Calendar API）

利用者が外部アプリで『カレンダーを連携』を選ぶ。
アプリは利用者をGoogleの認可画面へ移動させる。利用者はGoogle側で認証・同意する。
Googleの認可サーバーがアクセストークンを発行する。
外部アプリはそのトークンをGoogle Calendar APIへ提示し、許可された予定情報を取得する。

3ノードにまとめた概念図ですが、Googleの内部では認可サーバーとCalendar APIという別の論理的な役割があります。認可画面とAPIサーバーを「同じ画面」「同じエンドポイント」と誤解しないことが重要です。

4. 認可コード方式を6ステップで追う

現在のWebアプリやモバイルアプリで重要なのがAuthorization Code Grant（認可コード方式）です。利用者が承認したあと、いきなりブラウザのURLにアクセストークンを載せるのではなく、まず短命な認可コードを返し、それを別の通信でアクセストークンと交換します。

認可コードの流れ：ブラウザ・クライアント・認可サーバー

利用者のブラウザ

連携アプリ（Client）

認可サーバー（Googleなど）

クライアントがstateとPKCEのcode_challengeを用意し、利用者を認可エンドポイントへ誘導。
認可サーバー側で利用者を認証し、要求されたScopeへの同意を確認。
認可サーバーがクライアントの登録済みredirect_uriへ認可コードを返す。
クライアントが認可コードとcode_verifierをトークンエンドポイントへ送る。
認可サーバーがPKCEなどを検証し、アクセストークンを発行する。
クライアントはトークンをリソースサーバーのAPI呼び出しに使用する。

# 認可リクエスト例（説明用の架空ドメイン）
GET https://auth.example.com/authorize?
  response_type=code
  &client_id=calendar-helper
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=calendar.read
  &state=<random-state>
  &code_challenge=<S256-challenge>
  &code_challenge_method=S256

# 同意後：認可コードが戻る（トークンそのものではない）
https://app.example.com/callback?code=<code>&state=<state>

# クライアント→認可サーバー: HTTPSでコードを交換
POST https://auth.example.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=<code>
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=calendar-helper&code_verifier=<original-verifier>

5. アクセストークン・Scope・Refresh Tokenを具体的に

用語・語源	何をするもの？	身近な理解
Access Token（アクセス用の証票）	保護されたAPIにアクセスするための資格情報	『予定を読む権利』を示す通行証
Scope（範囲）	要求するアクセス権限の範囲を表す	予定を読む権限と編集する権限は分けて考える
Authorization Code（認可コード）	アクセストークンと交換する一時的なコード	通行証そのものではない引換券
Refresh Token（更新用トークン）	新しいアクセストークンの取得に使う場合がある	使い続けるための別の資格情報。発行が常に保証されるわけではない
Bearer Token（所持者提示型）	提示した者が利用できる形式の資格情報	漏えいすると他者に使われ得るため秘匿する
ID Token（OIDC）	認証結果に関するユーザーの情報を伝える	ログイン確認用。APIのアクセス権とは別

# API呼び出し例（教材用）
GET /v1/calendar/events HTTP/1.1
Host: api.example.com
Authorization: Bearer <access_token>

# 読み取り専用トークンを使って編集APIを呼ぶ
PATCH /v1/calendar/events/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer <read_only_token>

# 期待する結果：必要な権限がなければ拒否（例: 403）

Access Tokenの表現はJWTの場合も不透明な文字列の場合もあり、すべてのOAuthアクセストークンがJWTであるわけではありません。API側は適切な検証方法で有効期間、対象API（audience）、許可範囲などを確認します。Scopeの名前と意味もサービスごとの定義です。

6. PKCEとは？なぜ認可コードの横取りを防げる？

PKCEはProof Key for Code Exchangeの略。認可コード方式のクライアントが、最初に秘密のランダム値code_verifierを生成し、その値から計算したcode_challengeを認可リクエストで送ります。

PKCEの関係をノードで理解

クライアント（verifierを保持）

ブラウザ（codeを運搬）

認可サーバー（challengeと照合）

クライアントがcode_verifierを生成し、SHA-256等でcode_challengeを計算する。
認可リクエストではcode_challengeだけを送り、code_verifierは秘密に保持する。
コード交換時にcode_verifierを提示して照合し、一致しない交換を拒否する。

PKCEは『認可コードを他者に見られても、元のverifierがないと交換しにくくする』仕組みです。OAuth全体の盗聴対策をPKCEだけで代替できるわけではなく、HTTPSや安全なトークン保管も必要です。

7. OAuth・OIDC・SAML・SSOの違いを整理

技術の正式名称	主な目的	身近な例
OAuth 2.0（Open Authorization）	第三者アプリへのAPIアクセス権限の委任	別アプリにGoogleカレンダーの読み取りを許可
OIDC（OpenID Connect）	OAuth 2.0上で認証情報をやり取りする仕組み	『Googleでログイン』でID Tokenを利用
SAML（Security Assertion Markup Language）	主にXMLのアサーションを利用する認証連携	企業のID基盤からクラウド業務システムへSSO
SSO（Single Sign-On）	複数システムに個別ログインせず利用する体験・構成	社内ポータルの認証で複数SaaSを利用
JWT（JSON Web Token）	JSONクレームを持つトークン形式	OIDCのID Tokenなどに使われる
Google Password Manager	パスワードの保存と自動入力	SSOやOAuthそのものではない

8. もっと身近な例：許可すると何が起こるのか

会議日程を調整するWebアプリがカレンダーを読み取るケースで、利用者は同意画面を見て「読むだけなら許可」と判断できます。もし『全ファイルの編集』『メールの送信』まで要求されたら、用途に対して広すぎないか確認します。第三者アプリにパスワードを教える必要はありませんが、許可したAPI権限には実際の影響があることに注意してください。

画面や操作	技術的に何が起こる？	確認すること
『カレンダーへのアクセスを許可』	認可サーバーが同意内容を処理	誰が・どの範囲に・どれだけアクセスするか
『予定の閲覧だけ』を選ぶ	読み取り用のScopeを要求・許可	アプリが書き込み権限を要求していないか
連携を解除する	認可サーバーやサービス側で許可・トークンを失効させる場合がある	アプリ内データが自動削除されるとは限らない
期限切れ後に再び同期	新しいアクセストークンの取得や再認可が必要	Refresh Tokenの有無や失効条件はサービス次第
スマホアプリから連携	ブラウザ経由の認可とPKCEを用いる構成が一般的	アプリにユーザーのパスワードを入力させない

9. 操作ラボ：許可・拒否・権限不足を試す

Googleカレンダー、GitHub、Google Driveを例に、利用者が同意するか、閲覧や編集を許可するかを切り替えます。認可コードを発行する段階とトークン発行段階を分けて確認しましょう。実サービスへの通信は行いません。

INTERACTIVE AUTHORIZATION LAB

連携するアプリと許可範囲を操作する

外部サービスへの通信や認証は発生しない教材用の概念シミュレーターです。実在サービス固有の同意画面を再現するものではありません。

利用者が同意する予定の閲覧を許可予定の編集を許可

利用者
リソースオーナー

予定管理アプリ
クライアント

Googleの認可・APIサーバー
認可＋リソース

STEP 1 / 6

利用者が連携を開始

予定管理アプリが予定一覧へのアクセスを希望。利用者をGoogleの認可・APIサーバーの認可画面へ移動させます。

APIアクセスを試す（手順6で確認）

期限切れにする

APIアクセス：拒否

OAuthの権限は、サービス全体への無制限な操作権ではありません。リソースサーバー側でもトークンの有効性、対象API、権限などを検証します。

10. セキュアな実装で守ること

対策	守る対象	実務でのポイント
Authorization Code + PKCE (S256)	認可コードの横取り・注入	認可コード方式を用い、PKCEを実装する
HTTPS	トークンやコードの盗聴・改ざん	認可・トークン・APIの通信で利用する
redirect URIの厳密な照合	攻撃者のページへのリダイレクト	事前登録したURIと一致させる
state / リクエストとの紐付け	ログインCSRF・認可応答の取り違え	認可処理とブラウザセッションを関連付ける
Scope最小化	トークン流出時の被害拡大	閲覧のみなど必要な操作・対象に絞る
アクセストークンの検証	期限切れ・不適切な対象への使用	有効期限、発行元、対象API、権限をAPI側で確認
失効・更新の設計	長期に使われるトークンの悪用	更新トークンの保護、ローテーション等を検討
不要な古いフローを避ける	ブラウザ上の露出や認証情報の扱い	ImplicitやResource Owner Password Credentialsは現行BCPで非推奨

OAuth 2.0はトークンを持っている人にAPIへのアクセス能力を与え得るため、秘密情報として扱います。サーバー側のログにトークンを丸ごと記録しない、クライアントの画面に不要に露出させない、といった設計も重要です。

11. よくある疑問

Q. アクセストークンは誰が発行する？

認可サーバーです。APIを使いたいクライアントが独自に発行するのではありません。認可サーバーとリソースサーバーは同じ事業者のサービスの場合があります。

Q. 認可サーバーは利用者の電子証明書を送る？

OAuth 2.0の基本フローでは、利用者の電子証明書をクライアントへ配布する仕組みではありません。認証手段に証明書を使うシステムはありますが、OAuthのアクセス権委任の本質とは別です。

Q. アクセストークンがあればログインしていることになる？

いいえ。アクセストークンはAPIアクセスの認可を目的とします。ログインの認証連携にはOIDCなどを使用します。

Q. Scopeを付ければ必ず安全？

権限の細分化には役立ちますが、トークンの漏えい、誤った対象APIの受け入れ、広すぎる権限設定などを別途防ぐ必要があります。

Q. OAuthのトークンは必ずJWT？

いいえ。JWT形式でも不透明な文字列でも構いません。対象APIの適切な検証方式に従います。

Q. PKCEは何の略？

Proof Key for Code Exchangeです。認可コードをトークンに交換するクライアントが、元のランダム値の所持を証明する仕組みです。

参考仕様・公式資料

OAuth 2.0の基本仕様だけでなく、認可コードの安全な取り扱いはRFC 9700などの最新ベストプラクティスも確認してください。

RFC 6749: The OAuth 2.0 Authorization Framework（IETF / RFC Editor）
RFC 6750: Bearer Token Usage（IETF / RFC Editor）
RFC 7636: Proof Key for Code Exchange (PKCE)（IETF / RFC Editor）
RFC 9700: Best Current Practice for OAuth 2.0 Security（IETF / RFC Editor）
OpenID Connect Core 1.0（OpenID Foundation）
Google Calendar API: Choose Google Calendar API scopes（Google for Developers）
Authorizing OAuth apps（GitHub Docs）
OAuth 2.0（Microsoft identity platform）