OAuth認証の基本をまとめました。
自分の備忘録として整理したものですが、同じように認証周りで悩んでいる方の参考になれば。図解でフロー別の違いをまとめてみました。📝
はじめに
WebアプリやモバイルアプリでAPI連携をする際、「OAuth認証」という言葉をよく耳にします。この記事では、OAuth認証の基本概念から実装の流れまでを初心者向けにまとめました。何度も調べる手間を省くための備忘録としてもご活用ください。
OAuthとは？
OAuthは「Open Authorization」の略で、ユーザーの認証情報（ID・パスワード）を第三者のアプリケーションに渡すことなく、APIへのアクセス権を付与するための標準プロトコルです。
簡単に言えば：
- あなたがTwitterでログインする際に使うID・パスワードを
- 別のアプリ（例：TweetDeck）に渡さなくても
- そのアプリがあなたのTwitterアカウントでツイートできるようにする仕組み
なぜOAuthが必要なのか？
OAuthがない世界では、以下のような問題があります：
- セキュリティリスク: ユーザーが様々なアプリにID・パスワードを直接入力する必要がある
- アクセス制御の粒度: アプリに全ての権限を与えるか、全く与えないかの二択しかない
- アクセス権の管理: 一度パスワードを渡したら、そのアプリのアクセス権を後から取り消せない
OAuthはこれらの問題を解決するために設計されています。
OAuth 2.0の基本フロー
現在主流のOAuth 2.0には、いくつかの認可フローがありますが、最も一般的な「認可コードフロー」を説明します。
登場人物
- リソースオーナー: サービスを利用するユーザー（あなた）
- クライアント: OAuthを使ってAPIにアクセスしたいアプリ
- 認可サーバー: ユーザー認証と認可を行うサーバー
- リソースサーバー: 保護されたリソース（データ）を持つサーバー
認可コードフローの流れ
+--------+ +---------------+
| |--(A)- 認可リクエスト -------->| |
| | | 認可サーバー |
| |<-(B)- 認可コード ------------+| |
| | +---------------+
| クライアント|
| | +---------------+
| |--(C)- 認可コード+ | |
| | クライアント認証 -------->| トークンエンドポイント|
| |<-(D)- アクセストークン -------+| |
+--------+ +---------------+
+---------------+
| |
| |
+--------+ | リソースサーバー |
| |--(E)- アクセストークン ------->| |
| クライアント| | |
| |<-(F)- 保護されたリソース ------+| |
+--------+ +---------------+
- 認可リクエスト: クライアントはユーザーを認可サーバーにリダイレクト
- ユーザー認証: ユーザーは認可サーバーで認証（ログイン）
- 認可: ユーザーはクライアントに与える権限を確認・承認
- 認可コード発行: 認可サーバーはクライアントに認可コードを発行
- トークン交換: クライアントは認可コードをアクセストークンと交換
- APIアクセス: クライアントはアクセストークンを使ってAPIにアクセス
実装のための基本ステップ
1. アプリケーション登録
OAuthを利用するには、まずOAuthプロバイダ（Google, Twitter, GitHubなど）にアプリケーションを登録します。
例：GitHubの場合
1. GitHub > Settings > Developer settings > OAuth Apps > New OAuth App
2. 以下の情報を入力：
- Application name: あなたのアプリ名
- Homepage URL: アプリのホームページURL
- Authorization callback URL: コールバックURL
登録すると以下が発行されます：
- クライアントID: 公開可能な識別子
- クライアントシークレット: 秘密鍵（漏洩しないように管理）
2. 認可リクエストの作成
ユーザーを認可ページへリダイレクトするためのURLを作成します。
https://[認可サーバーのドメイン]/oauth/authorize?
client_id=[クライアントID]&
redirect_uri=[コールバックURL]&
response_type=code&
scope=[必要な権限の範囲]&
state=[CSRF対策の状態値]
※ stateパラメータはCSRF攻撃から保護するために重要です。ランダムな文字列を生成し、セッションに保存しておきましょう。
3. コールバックの処理
ユーザーが認可を許可すると、指定したリダイレクトURIにコードが付与されます。
https://[あなたのアプリのコールバックURL]?code=[認可コード]&state=[送信した状態値]
このコールバックで行うべき処理：
-
stateパラメータが元の値と一致することを確認（CSRF対策） - 認可コード（
code）を取得
4. アクセストークンの取得
認可コードを使ってアクセストークンを取得します。これはサーバーサイドで行う必要があります。
POST https://[認可サーバーのドメイン]/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&
code=[取得した認可コード]&
redirect_uri=[コールバックURL]&
client_id=[クライアントID]&
client_secret=[クライアントシークレット]
成功すると、以下のようなレスポンスが返ってきます：
{
"access_token": "ACCESS_TOKEN",
"token_type": "bearer",
"expires_in": 3600,
"refresh_token": "REFRESH_TOKEN",
"scope": "read write"
}
5. APIの呼び出し
取得したアクセストークンを使って、保護されたAPIを呼び出します。
GET https://[APIエンドポイント]/api/resource
Authorization: Bearer ACCESS_TOKEN
6. トークンの更新（オプション）
アクセストークンには有効期限があります。期限切れになった場合、リフレッシュトークンを使って新しいアクセストークンを取得します。
POST https://[認可サーバーのドメイン]/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&
refresh_token=[リフレッシュトークン]&
client_id=[クライアントID]&
client_secret=[クライアントシークレット]
主要なOAuth 2.0の認可フロー
1. 認可コードフロー（上述）
- Web アプリケーションに最適
- 最も安全なフロー
2. インプリシットフロー
- SPA（シングルページアプリケーション）向け
- リダイレクトURIにアクセストークンが直接付与される
- クライアントシークレットが不要
- ※セキュリティ上の懸念からPKCE付き認可コードフローが推奨されるようになっている
3. クライアントクレデンシャルフロー
- マシン間通信（サーバー間）に使用
- ユーザーの関与なしでアクセストークンを取得
4. リソースオーナー・パスワード・クレデンシャルフロー
- ユーザーのID/パスワードを直接使用
- 高度な信頼関係がある場合のみ使用（非推奨）
セキュリティに関する注意点
- HTTPS: すべての通信でHTTPSを使用する
- state パラメータ: CSRF攻撃対策として必ず使用する
- PKCE (Proof Key for Code Exchange): 公開クライアント向けのセキュリティ拡張
- スコープの最小化: 必要最低限の権限のみを要求する
- クライアントシークレットの保護: 漏洩しないようサーバーサイドでのみ使用する
開発に役立つライブラリ
Node.js
- Passport.js: 認証ミドルウェア
- node-oauth2-server: OAuth 2.0サーバーの実装
PHP
- League OAuth 2.0 Server
- PHP OAuth 2.0 Server
Python
- Authlib
- python-oauth2
Ruby
- Doorkeeper
- OAuth2 gem