OAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説

OAuthとは何か - 認可の仕組みを整理する

OAuth 2.0は、あるユーザー（Resource Owner）が保有するリソースに対して、第三者アプリ（Client）が必要最小限の権限だけを持ってアクセスするための枠組みです。パスワードを渡さず、代わりに「アクセストークン」を発行して権限を委譲します。

OAuth 2.0の定義と役割

RFC 6749では、OAuth 2.0を「サードパーティアプリケーションに対して、HTTPサービスへの限定的なアクセスを許可するための認可フレームワーク」と定義しています。ここで重要なのは認可（authorization） という語です。ユーザーが誰かを確認する認証とは目的が別で、「このアプリはこのユーザーのカレンダー読み取りだけできる」といった権限の範囲を委譲するのがOAuthの仕事になります。

一次情報として、RFC 6749（OAuth 2.0 Authorization Framework）を確認しておくと、用語と登場人物の対応関係が正確に押さえられます。

「認証」と「認可」の違い - よくある混同

案件でOAuthを扱うとき、真っ先に整理しておきたいのが認証と認可の違いです。混同したまま実装すると、本来は認証ではないOAuthアクセストークンを「ログイン済みの証拠」として扱ってしまい、なりすまし経路を作ってしまうことがあります。

OAuth 2.0単体は認可の仕組みです。「ユーザーが誰か」を確かめたい場合は、OAuth 2.0の上にOpenID Connect（OIDC） を重ねて使います。この関係は後述します。

OAuth 1.0と2.0の違い - 現在は2.0系が主流

OAuth 1.0はリクエストごとに署名を必要とし、実装コストが高い仕様でした。2012年に公開されたOAuth 2.0（RFC 6749）ではTLSに依存する前提でシンプル化され、以降のIdP・SaaSは2.0系の実装が主流になっています。執筆時点では、Google・GitHub・Microsoft・LINE等の主要プロバイダーがOAuth 2.0ベースのAPIを提供しています。

さらに2024年以降は、後述のOAuth 2.1が現行仕様の整理と非推奨事項の除外を進める形でドラフト化されており、公式リリースノートやIETF側の進行状況を随時確認するのが安全です。

ミニFAQ

• Q: OAuth 2.0とOpenID Connectはどちらを使えばいい？

• A: 「ログイン機能を作る」目的ならOpenID Connectが必要です。「API利用の権限委譲」だけならOAuth 2.0で足ります。両方の要件があるIdP実装ではOIDC（OAuth 2.0上のレイヤー）が選ばれます。

OAuth 2.0の登場人物と主要トークン

OAuth 2.0の仕様を読むと、必ず4つの役割と3種類のトークンが出てきます。案件で実装レビューをするときの共通言語になるため、最初に押さえておくと後段が読みやすくなります。

4つの登場人物

認可サーバーとリソースサーバーは、同じ組織が運用しても分離しても構いません。SaaS事業者のAPIでは同一ドメインで運用されることが多く、社内IdP＋複数マイクロサービスの構成では分離されることが多い傾向があります。

アクセストークン・リフレッシュトークン・認可コード

トークン類は名前が似ていて、実装時に取り違えやすい要素です。それぞれの用途をきちんと分けて設計する必要があります。

• 認可コード（Authorization Code）：ユーザー同意直後に発行される短命の使い捨てコード。クライアントはこれをアクセストークンと交換します

• アクセストークン（Access Token）：APIリクエストのAuthorizationヘッダで送信し、リソースサーバーが検証する短命トークン。有効期限は数分〜数時間程度に設計されるケースが多いです

• リフレッシュトークン（Refresh Token）：アクセストークンの再取得に使う長寿命トークン。ユーザーの再ログインなしでアクセストークンを更新できます

アクセストークンの実体は仕様上「不透明な文字列」でよく、JWT形式で内容をエンコードするパターン（Self-Contained Token）と、認可サーバー側で状態を保持するパターン（Introspection方式）があります。SaaS側の設計に合わせて選択します。

スコープと同意画面

スコープ（scope） は、アクセストークンが持つ権限範囲を文字列で表す仕組みです。Googleなら「calendar.readonly」、GitHubなら「repo」「read:user」のように、サービスごとに命名が定義されています。

ユーザーは同意画面（Consent Screen）でクライアントが要求するスコープを確認して同意します。ここで必要最小限のスコープに絞ることが実装原則になります。過剰権限は同意率も下げ、事故時の被害範囲も大きくします。

4つの主要なグラントタイプと使い分け

OAuth 2.0の実装で最初に迷うのが「どのグラント（フロー）を選ぶか」です。クライアントの種類とセキュリティ要件で決まります。まず結論として、現在の実装ではAuthorization Code Grant + PKCEを基準に、サーバ間はClient Credentials、TV/IoTはDevice Authorization、と場合分けするのが一般的です。

Authorization Code Grant（Web/モバイル/SPAの標準）

ユーザーの同意を挟むフロー全般で最初に検討する形式です。仕組みを要約すると次の流れになります。

1. クライアントがユーザーを認可サーバーへリダイレクト

2. ユーザーがログイン・同意

3. 認可サーバーがクライアントへ認可コードを返す

4. クライアントがバックエンドで認可コードとアクセストークンを交換

認可コードはブラウザを経由するため一度公開URLに乗りますが、アクセストークンとの交換はサーバサイド（またはPKCE付きクライアント）で行うため、トークン自体がURLに露出しません。SPAやモバイルアプリでも、後述のPKCEと組み合わせて用います。

Client Credentials Grant（サーバ間連携）

ユーザーの同意が不要で、クライアント自身が認可主体になる形式です。バッチ処理、内部システム間連携、Machine to Machineの用途で選ばれます。認可サーバーへclient_idとclient_secretを提示してアクセストークンを取得します。ユーザーコンテキストが必要な処理には使えない点に注意が必要です。

Refresh Token Grant

アクセストークンの有効期限が切れたとき、リフレッシュトークンを使って新しいアクセストークンを取得するフローです。ユーザーに再ログインを強いず、かつアクセストークンの寿命は短く保てるため、セキュリティと利便性の折衷として使われます。リフレッシュトークンの盗難対策として、ローテーション（使い捨て化）や再利用検知の実装が推奨されています。

Device Authorization Grant（TV・IoT）

ブラウザ入力が困難なデバイス（スマートTV、CLIツール、IoT機器等）向けに、RFC 8628で定義されたフローです。デバイスにユーザーコードを表示し、ユーザーは別デバイス（スマホ・PC）でそのコードを入力して認可します。GitHub CLIやAWS CLIのSSOログインなどで見られる形式です。

非推奨になったフロー（Implicit / Resource Owner Password Credentials）

OAuth 2.0の初期仕様には次の2つが含まれていましたが、現在は非推奨です。

• Implicit Grant：SPA向けにブラウザに直接アクセストークンを返す形式。トークンがURLフラグメントに露出する等の弱点があり、現在はAuthorization Code + PKCEへの置き換えが推奨されています

• Resource Owner Password Credentials（ROPC）Grant：ユーザーのパスワードをクライアントに直接渡す形式。OAuthの原則（パスワードを渡さない）に反するため、OAuth 2.1では削除の方向で整理されています

ミニFAQ

• Q: SPA（React、Vue等）ではどのグラントを選ぶ？

• A: Authorization Code Grant + PKCE が現在の推奨です。かつてのImplicit Grantは避け、認可サーバー側がPKCE対応していない場合は代替IdPを検討します。

PKCEとOAuth 2.1 - 現在推奨されるフロー

PKCE（Proof Key for Code Exchange、ピクシーと読まれることが多い）は、認可コードの盗聴・傍受に対する追加防御を提供する拡張仕様です。SPAやモバイルアプリのようにclient_secretを安全に保管できないクライアントでも、Authorization Code Grantを安全に使えるようにする目的で設計されました。

PKCEの仕組みと必要性

クライアントは認可リクエスト時にランダムなcode_verifierを生成し、そのハッシュ（code_challenge）を認可サーバーに送信します。アクセストークンとの交換時に元のcode_verifierを提示することで、認可コードを傍受した攻撃者がトークン取得を完遂できないようになります。

PKCEの詳細はRFC 7636を確認してください。当初はモバイル向けの拡張として登場しましたが、現在はWebアプリを含むすべてのAuthorization Code Grantで推奨されるようになっています。

OAuth 2.1の変更点

OAuth 2.1は、RFC 6749以降に追加されたベストプラクティスやセキュリティ勧告を整理し、非推奨事項を除いた統合仕様として策定が進められています。執筆時点（2026年7月時点）ではIETFのドラフト段階であり、正式RFCとしては確定していません。したがって以下は「ドラフトで示されている方向性」であり、現行の制度的事実というより実務上の推奨と読むのが安全です。

• Authorization Code GrantでPKCEを必須化する方向

• Implicit Grant と ROPC Grant の削除

• リフレッシュトークンのSender Constrained 化またはローテーション推奨

• redirect_uriは完全一致での事前登録

進捗はOAuth 2.1 draftで追えます。ドラフト段階でも実装コミュニティでは方向性に沿った設計が広く推奨されていますが、公式RFC化状況を随時確認したうえで設計に反映するのが安全です。

OpenID Connect（OIDC）との違い

OpenID ConnectはOAuth 2.0の上に認証機能を載せるプロトコルです。OAuth 2.0が認可のみを扱うのに対し、OIDCは「このリクエストは誰の同意によるものか」を暗号的に伝えるIDトークンを追加します。

OIDCは「認証」を追加するレイヤー

OIDCの正式仕様はOpenID Connect Core 1.0に定義されています。OAuth 2.0のAuthorization Code Grantとほぼ同じフローに、scope=openidの指定とIDトークンの発行を加えたものと理解しておくと、実装時の見通しが良くなります。

IDトークンとアクセストークンの違い

IDトークンをリソースサーバーの認可判断に使ったり、逆にアクセストークンをログインの証拠に使ったりする混同は事故につながります。役割を分けて実装するのが原則です。

セキュリティ上の実装注意点

OAuthを実装する側で、案件のコードレビューで頻繁に指摘される観点をまとめます。仕様書だけでは伝わりにくい実装細部でのミスが多い領域です。

redirect_uriの検証

認可サーバー側では、事前登録されたredirect_uriと完全一致で検証する設計が推奨されます。前方一致やワイルドカードでの緩い検証は、認可コードを攻撃者側にリダイレクトさせるオープンリダイレクト脆弱性の温床になります。OAuth 2.1でも完全一致が明確化される方向で整理されています。

state パラメータでCSRF対策

認可リクエスト時に生成した推測困難な文字列をstateとして渡し、コールバック時に照合します。stateを検証していないと、攻撃者が自分の認可コードを被害者のセッションに紐付けるCSRF系のなりすましが成立し得ます。省略はしないのが原則です。

トークン保管（Cookie / localStorage）

SPAにおけるアクセストークンの保管場所は、実装現場で頻繁に議論になる論点です。傾向としては次のような設計が採用されるケースが多いですが、要件・脅威モデルによって選択が変わります。

• Cookie（HttpOnly、Secure、SameSite=Lax以上）：JavaScriptから直接読めない点でXSS耐性は上がりますが、CSRF対策・BFF構成の有無・SameSite設定次第で安全性の前提が変わるため「Cookieなら安全」と単純化できません

• localStorage：JavaScriptから読めるためXSSリスクが高く、OWASP等では非推奨とされることが多い

• メモリ内保持＋短命トークン＋Refresh Token Rotation：モダンな折衷案として採用されるケースがあります

いずれの方法にも一長一短があるため、「一択」と決めつけず、案件のリスク許容度と運用体制で選ぶ姿勢が必要です。

スコープ最小化と有効期限設計

同意時に要求するスコープは、実際に必要な最小権限に絞ります。「とりあえずread:all」のような雑な設計は、事故時の被害範囲を広げる原因になります。アクセストークンの有効期限は用途によって数分〜数時間、リフレッシュトークンは数日〜数十日を目安に、業務要件に応じて短くする設計が一般的です。

一次情報として、RFC 6819（OAuth 2.0 Threat Model and Security Considerations）を通読しておくと、実装レビュー観点の抜け漏れを減らせます。攻撃パターンごとの緩和策が整理されており、対策のチェックリストとして使いやすい構成です。

ミニFAQ

• Q: SPAでリフレッシュトークンは使ってよい？

• A: OAuth 2.1の方向性ではPKCE + Refresh Token Rotationの併用は許容されつつあります。ただしlocalStorageに素で置くのは避け、短命化とローテーション、再利用検知をセットで実装する設計が望ましいでしょう。

フリーランスエンジニアの案件事例 - OAuth周辺スキルはどこで使われるか

OAuthは「専門家だけが触る領域」に見えますが、実際にはバックエンド開発・SPA構築・SSO案件・SaaS連携 で頻繁に登場します。ここでは、フリーランスエージェント各社の公開案件で観測される4つのパターンを整理します。

SaaS連携開発

SlackやGoogle Workspace、Salesforce、Notion等のSaaSのAPIを既存プロダクトに統合する案件です。OAuth 2.0のAuthorization Code Grantでユーザー同意を受け、リフレッシュトークンでバックグラウンド同期を維持するパターンが典型的です。FastAPIやNode.js、Djangoなどのバックエンドフレームワーク経験と組み合わせて募集されるケースが目立ちます。

社内SSO・IdP導入

Okta、Auth0、Azure AD（Microsoft Entra ID）、Keycloakなどを使い、社内アプリケーション群の認証・認可基盤を構築する案件です。OIDCによるSSOがベースになり、必要に応じてSAML連携やSCIMプロビジョニングも扱います。セキュリティ要件が厳しめの官公庁・公共系案件や、上場企業のセキュリティ強化施策で募集されることがあります。

モバイル・SPA認可基盤

自社SaaSでモバイルアプリやSPAを提供する場合、Authorization Code Grant + PKCEをベースにトークン運用の設計が必要になります。Next.jsやNestJS、Laravel Sanctum/Passportを絡めた案件で観測できます。SaaSスタートアップ案件でも認可基盤の構築・改修は頻出テーマです。

サーバレス・API Gateway上の認可

AWS Lambda と API Gateway、Cognitoを組み合わせた認可基盤や、Lambda Authorizerでのアクセストークン検証を任される案件もあります。認可設計はインフラ側の設計と密接に絡むため、クラウドエンジニア とバックエンドエンジニア の境界に位置するスキルセットになります。

想定単価レンジ

以下は、2026年時点で国内主要フリーランスエージェント（レバテックフリーランス・ITプロパートナーズ・フリコン等）の公開案件のうち、OAuth・OIDC・IdP関連要件を含む案件を目視で集計した参考レンジです。週4〜5日相当の常駐・準常駐案件を中心に見ており、週2〜3日の稼働率が下がる案件は同じスキル要件でも月額が下がる傾向があるため別枠で捉えてください。地域・商流・稼働率・実務経験年数で変動します。

上記は公開案件から観測した範囲であり、非公開案件や大手直請け、より高スキル層を含めるとレンジは変動します。単価は工数・稼働率・契約形態でも変わるため、契約前に条件確認を行うのが前提です。関連する資格情報として、情報セキュリティマネジメント試験や、セキュリティエンジニアのキャリアパスもあわせて参考にしてください。

OAuth 2.0実装レビューチェックリスト（独自整理）

現場のコードレビューで確認すべき観点を、実装工程順にまとめました。案件参画時のセルフチェックや、レビュワー側の観点抜けを防ぐチェックとして使えます。

設計フェーズ

• クライアント種別（Confidential / Public）を明確化しているか

• ユーザー同意が必要な用途か、Machine-to-Machineかを区別してグラントを選んでいるか

• スコープは業務要件に対して最小化されているか

• 認可サーバーがPKCE対応か、対応していない場合の代替を検討したか

認可リクエスト

• state パラメータを毎回生成し、コールバックで照合しているか

• SPA/モバイルはPKCE（code_verifier + code_challenge）を使っているか

• redirect_uriが認可サーバー側に完全一致で登録されているか

• 不要なスコープを要求していないか

トークン交換・保管

• 認可コードは一度だけ、期限内に交換しているか

• Client Secretはサーバ側の安全な場所（環境変数・シークレットマネージャー）に保管されているか

• アクセストークンの有効期限は短命化されているか

• リフレッシュトークンはローテーション（使い捨て化）されているか

• SPAでlocalStorageに素で保存していないか

リソースアクセス

• リソースサーバーはアクセストークンの署名・有効期限・スコープを検証しているか

• Introspection方式の場合、失効チェックの頻度は妥当か

• リソースサーバー側で認可判断に使うクレームを明確化しているか

運用

• 監査ログにトークン発行・失効・拒否イベントを記録しているか

• 異常検知（同一トークンの多重利用、地理的異常）の仕組みがあるか

• IdP側のセキュリティアラート・更新通知を継続的にフォローしているか

このチェックリストは、RFC 6819とOAuth 2.0 Security Best Current Practiceの観点を、実案件のレビュー経験を踏まえて整理したものです。仕様更新に合わせて随時見直すのが前提の運用ドキュメントとしてお使いください。

まとめ

OAuth 2.0は「パスワードを渡さず、必要最小限の権限をトークンとして委譲する認可の仕組み」であり、フリーランスエンジニアがSaaS連携・SSO・SPA認可基盤の案件で必ず触れる基礎知識です。要点を振り返ります。

• OAuth 2.0は認可を扱い、認証を扱うOpenID Connectとは目的が違う

• 現在の推奨はAuthorization Code Grant + PKCE、サーバ間はClient Credentials

• Implicit GrantとROPC Grantは非推奨で、OAuth 2.1で整理される方向

• 実装で事故る4大ポイントはredirect_uri検証・state・トークン保管・スコープ設計

• SaaS連携・SSO・認可基盤設計はフリーランス案件で継続的に需要がある領域

次のステップとして、案件で扱うSaaSやIdPの仕様書と、RFC 6749、RFC 7636、RFC 6819を読み合わせるのが実践的です。SaaS連携やSSO案件を探している方は、フリコンの非公開案件も含めて相談してみてください。

参照した一次情報

• RFC 6749 - The OAuth 2.0 Authorization Framework

• RFC 7636 - Proof Key for Code Exchange

• RFC 6819 - OAuth 2.0 Threat Model and Security Considerations

• RFC 8628 - OAuth 2.0 Device Authorization Grant

• OpenID Connect Core 1.0

• OAuth 2.1 draft

• OAuth 2.0 Security Best Current Practice