OAuth 2.0 は、ユーザーのパスワードそのものをアプリに渡さず、あるサービスのデータや機能へのアクセス権だけを別のアプリに委譲するための認可フレームワークです。ログインそのものを扱う仕組みではなく、何をどこまで許すか を制御する点が中心になります。Web サービス連携、モバイルアプリ、API 連携、自動化ツールで非常によく使われます。
認可コード・トークン・リダイレクトの流れ
OAuth 2.0 の基本は、ユーザーがサービス提供側の画面で許可を与え、アプリはその結果としてトークンを受け取る流れです。アプリは最初に認可サーバーへ飛び、ユーザーはそこでログインして同意します。その後、アプリは一時的な認可コードを受け取り、それを使ってアクセストークンを取得します。
この分離が重要です。アプリがユーザーのパスワードを受け取らないため、認証情報の流出リスクを減らせます。また、アプリごとに許可範囲を絞れるので、必要以上の権限を渡さずに済みます。
代表的な登場人物
- リソースオーナー: 権限の持ち主であるユーザー
- クライアント: アクセスしたいアプリ
- 認可サーバー: 許可を確認し、トークンを発行する側
- リソースサーバー: API やデータ本体を提供する側
スコープで決める許可の範囲
OAuth 2.0 では、どの操作を許すかを scope で表します。scope は「読み取りのみ」「メールアドレスの閲覧」「カレンダーの更新」など、サービスが定義する権限の単位です。アプリは必要な scope だけを要求し、ユーザーはその内容を見て同意します。
scope を細かく分けるほど、安全性は高めやすくなります。ただし細かすぎると、利用者が同意画面で判断しにくくなるため、実務では「少なすぎず、広すぎない」設計が重要です。特に業務システムでは、書き込み権限を安易にまとめないことが大切です。
アクセストークンとリフレッシュトークン
OAuth 2.0 で実際に API へ持っていくのは、通常 アクセストークン です。これは短い有効期限で発行されることが多く、漏えい時の影響を抑えます。期限が切れたら、条件を満たす場合に リフレッシュトークン を使って新しいアクセストークンを取得します。
両者の役割は次のように分かれます。
| トークン | 役割 | 典型的な扱い |
|---|---|---|
| アクセストークン | API にアクセスするための証明 | 短命、頻繁に更新 |
| リフレッシュトークン | 新しいアクセストークンを再発行するための証明 | より慎重に保管 |
リフレッシュトークンは便利ですが、保管場所を誤ると長期的な不正利用につながります。特にクライアント側の実装では、保存先や削除タイミングを慎重に設計します。
認可コードフローがよく使われる理由
OAuth 2.0 には複数の方式がありますが、Web アプリや一般的なサーバー連携では 認可コードフロー が基本です。これは、ユーザーが許可した後に一時コードを経由するため、トークンを直接ブラウザ上に露出しにくい構成になっています。
以前は暗黙的な流れを使う場面もありましたが、現在は安全性の観点から認可コードフローが広く推奨されます。特に、サーバー側でクライアントシークレットを保持できる構成では、この方式が扱いやすく、実装上も整理しやすいです。
OAuth 2.0 と OpenID Connect の違い
OAuth 2.0 は 認可 の仕組みであり、ユーザーが誰かを証明する 認証 の仕組みではありません。ここを混同しやすいため注意が必要です。ログイン機能として見える場面でも、実際には OAuth 2.0 の上に OpenID Connect を重ねていることがあります。
| 観点 | OAuth 2.0 | OpenID Connect |
|---|---|---|
| 主な目的 | アクセス権の委譲 | ユーザー認証 |
| 扱うもの | scope、アクセストークン | ID トークン、ユーザー情報 |
| よくある用途 | API 連携、外部アプリ連携 | ソーシャルログイン、SSO |
つまり、OAuth 2.0 だけでは「このユーザー本人である」とは言えません。本人確認が必要なら、認証層を別に考える必要があります。
API 連携で実装するときのつまずき
実装では、redirect URI の一致、トークンの保存場所、期限切れ処理、scope の過不足でつまずきやすいです。特に redirect URI は、認可サーバー側に登録した値と厳密に一致していないと失敗することがあります。また、エラーが起きたときに、どの段階で失敗したのかを切り分けにくい点も実務上の難しさです。
Python で API を叩く場合も、OAuth 2.0 の本質は変わりません。ライブラリが認可 URL の生成やトークン更新を肩代わりしてくれても、設計上は「どの権限を、誰の同意で、どの期間使うか」を自分で理解しておく必要があります。これが曖昧だと、動いていても運用で困ります。
実務で意識したい点
- 必要最小限の scope に絞る
- アクセストークンは短命にする
- リフレッシュトークンの保管場所を明確にする
- 認証と認可を混同しない
- 失敗時のログに、どの段階のエラーかを残す
OAuth 2.0 は、単なる「外部ログインの仕組み」ではなく、権限を安全に分けて扱うための基盤です。API 連携が増えるほど、この考え方は重要になります。サービスアカウントや IAM のような別の認可方式と使い分けることで、個人ユーザー起点の連携とシステム間連携を整理しやすくなります。
