はじめに
外部サービスのAPIを利用するとき、利用者のIDやパスワードを別のアプリへ渡さずに、必要なデータや機能だけを使わせたいことがあります。そのための代表的な仕組みがOAuth 2.0です。
OAuth 2.0では、利用者が許可した範囲に基づいてアクセストークンを発行し、クライアントはそのトークンを使って保護されたAPIへアクセスします。この記事では、OAuth 2.0の役割、アクセストークンの意味、Authorization Codeを使う代表的な流れ、認証との違いを整理します。読み終えると、アクセストークンを使ったAPIアクセスの基本を説明できるようになります。
この記事で分かること
- OAuth 2.0が何のための仕組みか
- OAuth 2.0に登場する4つの役割
- アクセストークンが何を表すのか
- Authorization Codeを使ってAPIへアクセスする基本の流れ
- OAuth 2.0と認証の違い
OAuth 2.0とは
OAuth 2.0は、クライアントが利用者のパスワードを受け取らずに、利用者が許可した範囲で保護されたリソースへアクセスするための認可フレームワークです。
例えば、写真管理サービスのデータへ印刷アプリからアクセスしたい場合、印刷アプリへ写真管理サービスのパスワードを渡すのではなく、写真へのアクセスだけを許可できます。許可された内容はアクセストークンとしてクライアントへ渡され、APIアクセス時の資格情報として使われます。
OAuth 2.0の中心は「誰であるかを証明すること」ではなく、「どのリソースへ、どの範囲でアクセスを許可するか」です。
OAuth 2.0に登場する4つの役割
OAuth 2.0では、次の4つの役割を区別すると流れを理解しやすくなります。
| 役割 | 意味 | 例 |
|---|---|---|
| リソースオーナー | 保護されたリソースへのアクセスを許可できる主体 | 自分の写真やファイルを持つ利用者 |
| クライアント | リソースへアクセスしたいアプリ | 印刷アプリや連携アプリ |
| 認可サーバー | 許可を確認し、アクセストークンを発行するサーバー | サービスの認可を担当するサーバー |
| リソースサーバー | 保護されたAPIやデータを提供するサーバー | 写真APIやファイルAPI |
利用者は認可サーバーを通じてクライアントへアクセスを許可し、クライアントは取得したアクセストークンをリソースサーバーへ提示します。
アクセストークンとは
アクセストークンは、クライアントへ与えられた認可を表し、保護されたリソースへアクセスするために使う資格情報です。トークンには、アクセスできる範囲や有効期間などの情報が関連付けられます。
重要なのは、アクセストークンが利用者のパスワードそのものではないことです。クライアントはパスワードを保持せず、認可サーバーから発行されたトークンを使ってAPIへアクセスできます。
API側は受け取ったトークンを検証し、要求された操作が許可された範囲に含まれる場合だけリソースを返します。
アクセストークンでAPIへアクセスする基本の流れ
ここでは、OAuth 2.0で広く使われるAuthorization Codeを使う流れを例にします。Authorization Codeを使う場合は、認可コードの横取りや不正利用を防ぐため、PKCEを組み合わせることが現在の基本的な対策です。
1. 利用者へ認可を求める
クライアントは利用者を認可サーバーへ移動させ、「このアプリに、指定した範囲へのアクセスを許可するか」を確認します。許可する範囲はscopeで表します。
2. 認可コードを受け取る
利用者が許可すると、認可サーバーはクライアントへ認可コードを返します。認可コードはAPIを直接呼び出すためのトークンではなく、アクセストークンを取得するための一時的な情報です。
3. アクセストークンを取得する
クライアントは認可コードを認可サーバーのtoken endpointへ送り、条件を満たすとアクセストークンを受け取ります。PKCEを使う場合は、この交換時に事前に対応付けたcode verifierも確認されます。
4. APIへアクセストークンを提示する
クライアントはアクセストークンを付けてリソースサーバーのAPIを呼び出します。Bearer Tokenを使う場合は、HTTPのAuthorizationヘッダーで次のように送ります。
Authorization: Bearer <access_token>リソースサーバーはトークンを検証し、有効で必要な権限を持つ場合にリクエストを処理します。REST APIを使って外部サービスの機能を呼び出す全体像は、REST APIで他サービスの予測モデルを活用方法：初心者向で確認できます。
OAuth 2.0と認証の違い
OAuth 2.0の目的は認可です。認証は「誰なのか」を確認することで、認可は「何を許可するか」を決めることです。両者の一般的な違いは、アクセス制御とは？認証・認可との違いと最小権限の基本を解説で整理しています。
OAuth 2.0の処理中に利用者が認可サーバーへログインすることはありますが、その事実だけでクライアントが利用者の本人確認情報を受け取れるわけではありません。利用者の認証結果やID情報をクライアントへ伝える標準的な仕組みには、OAuth 2.0の上に構築されたOpenID Connectがあります。
したがって、「OAuthでログインする」という表現を見かけても、OAuth 2.0そのものの役割と、OpenID Connectなどによる認証の役割は分けて考える必要があります。
安全に利用するための基本
アクセストークン、とくにBearer Tokenは、保持している主体が利用できる資格情報です。漏えいすると第三者に使われる可能性があるため、HTTPSで送信し、URLのクエリパラメータへ含めないようにします。ログにも不用意に記録しないことが重要です。
また、クライアントへ必要以上のscopeを要求させず、必要な範囲だけを許可します。Authorization Codeを使うフローではPKCEを利用し、認可コードが盗まれても別のクライアントから交換されにくくします。
アクセストークンの有効期間、refresh tokenの発行有無、保存方法などはサービスやクライアントの種類によって異なります。固定的な方法を当てはめず、利用する認可サーバーの仕様とセキュリティ要件に従って管理します。
まとめ
OAuth 2.0は、クライアントが利用者のパスワードを受け取らずに、許可された範囲で保護されたリソースへアクセスするための認可フレームワークです。
利用者の許可をもとに認可サーバーがアクセストークンを発行し、クライアントはそのトークンをリソースサーバーへ提示してAPIへアクセスします。Authorization Codeを使う代表的な流れでは、PKCEを組み合わせることが現在の基本的なセキュリティ対策です。
OAuth 2.0は認証そのものを定義する仕組みではありません。「誰なのか」を扱う認証と、「何を許可するか」を扱う認可を分けて理解すると、アクセストークンがAPI連携で果たす役割を整理しやすくなります。
関連記事
