クライアントクレデンシャル - クライアントクレデンシャルフロー
サーバー間通信（M2M）向けのフロー。ユーザーの関与なしにクライアント自身の認証情報でトークンを取得する。
概念図
実例
トークンエンドポイントへのリクエスト（client_id + client_secret）
bash
curl -X POST https://auth.example.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_CLIENT_SECRET" \
-d "scope=read:reports write:logs"取得したアクセストークンで API にアクセスする例
bash
# 取得したアクセストークンで API にアクセス
curl -X GET https://api.example.com/v1/reports \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." \
-H "Accept: application/json"クレデンシャルを環境変数で安全に管理する例
bash
# クレデンシャルを環境変数で管理
export CLIENT_ID="your-client-id"
export CLIENT_SECRET="your-client-secret"
curl -X POST https://auth.example.com/oauth/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=${CLIENT_ID}" \
-d "client_secret=${CLIENT_SECRET}"フローの全体像
クライアントクレデンシャルフローは、ユーザーが関与しないサーバー間通信（Machine-to-Machine: M2M）に特化した OAuth 2.0 のグラントタイプです。
処理の流れ
- クライアント（バックエンドサービス）が
client_idとclient_secretを認可サーバーのトークンエンドポイントに送信する - 認可サーバーがクライアントの資格情報を検証し、アクセストークンを発行する
- クライアントはアクセストークンを使ってリソースサーバーの API にアクセスする
認可コードフローや PKCE フローと異なり、ブラウザのリダイレクトやユーザーの同意画面は存在しません。
主なユースケース
- マイクロサービス間通信: サービス A がサービス B の API を呼び出す場合
- バッチ処理・定期ジョブ: 夜間バッチが外部 API からデータを取得する場合
- 管理ツール・CLI: 管理者向けの自動化スクリプトが API を操作する場合
- IoT デバイスのバックエンド: デバイス管理サーバーがクラウド API と通信する場合
セキュリティ上の注意点
クライアントクレデンシャルフローでは、client_secret がそのまま認証に使われるため、その管理が最も重要です。
クレデンシャルの安全な管理
- ソースコードに直接埋め込まない: 環境変数、シークレット管理サービス（AWS Secrets Manager, HashiCorp Vault 等）を使用する
- ログに出力しない: リクエストログやエラーログに
client_secretが含まれないよう注意する - 定期的にローテーションする: クレデンシャルを定期的に更新し、漏洩時の影響を抑える
スコープの制限
- トークンリクエスト時に必要最小限のスコープを指定する
- 認可サーバー側でクライアントごとに許可スコープを制限する
- 管理操作と読み取り操作でクライアントを分離することも有効
トークンの有効期限
- アクセストークンの有効期限は短く設定する（推奨: 15-60 分）
- クライアントクレデンシャルフローでは通常リフレッシュトークンは発行されない（クレデンシャル自体で再取得が可能なため）
- 有効期限切れ時は新しいトークンをリクエストする実装にする