クライアントクレデンシャルフロー

ユーザーが関与しないマシン間（M2M）通信のためのフロー。クライアント自身の資格情報でトークンを取得します。バックエンドサービス間の通信に適しています。

M2M通信のユースケース

マイクロサービス間通信

バックエンドサービスAがサービスBのAPIにアクセスする場合。ユーザーのリクエストを処理する過程で、他のサービスにアクセスする際に使用します。

例: 注文サービス → 在庫サービス、決済サービス → 通知サービス

バッチ処理・cronジョブ

定期的に実行されるバックグラウンドジョブがAPIにアクセスする場合。ユーザーの介入なしで自動的にデータを処理します。

例: 日次集計バッチ、定期レポート生成、データ同期ジョブ

CLIツール・管理ツール

サーバー上で実行される管理ツールやCLIがAPIにアクセスする場合。デプロイスクリプトや監視ツールなどで使用します。

例: デプロイスクリプト、監視エージェント、管理CLI

IoTデバイス（サーバーサイド処理）

IoTデバイスからのデータを集約するサーバーが、分析APIにアクセスする場合。デバイス自体ではなく、集約サーバーが認証主体になります。

例: IoTゲートウェイ → クラウドAPI

ユーザーコンテキストがない点に注意

クライアントクレデンシャルフローではユーザー情報がトークンに含まれません。アクセス制御はクライアント単位になるため、「誰の代理でアクセスしているか」を区別する必要がある場合は、認可コードフロー等のユーザー参加型フローを使用してください。

シーケンス図

クライアント

認可サーバー

リソースサーバー

>1. トークンリクエスト

<2. トークンレスポンス

>3. リソースアクセス

各ステップの詳細

トークンリクエスト

クライアント → 認可サーバー

クライアントが自身の資格情報（client_id と client_secret）を使って、直接トークンエンドポイントにリクエストします。認可エンドポイントは使用しません。

リクエスト

POST /token

Content-Type: application/x-www-form-urlencoded

Authorization: Basic base64(client_id:client_secret)

grant_type=client_credentials&scope=api:read api:write

セキュリティノート

!client_secret は安全に管理する必要がある
!Basic 認証またはPOSTボディでクライアント認証を行う

トークンレスポンス

認可サーバー → クライアント

認可サーバーがクライアントを認証し、アクセストークンを発行します。リフレッシュトークンは通常発行されません。

リクエスト

POST /token

レスポンス

200 /token

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "api:read api:write"
}

セキュリティノート

!リフレッシュトークンは発行しない（再認証が容易なため）
!トークンの有効期限は短く設定する

リソースアクセス

クライアント → リソースサーバー

取得したアクセストークンでリソースサーバーのAPIにアクセスします。

リクエスト

GET /api/data

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

レスポンス

200 /api/data

{
  "data": [
    {
      "id": 1,
      "value": "サービスデータ"
    }
  ]
}

セキュリティノート

!リソースサーバーはスコープに基づいてアクセスを制御する

使うべき場面

+バックエンドサービス間のAPI通信（M2M）
+バッチ処理やcronジョブ
+マイクロサービス間の通信
+CLIツールやデーモンプロセス

使うべきでない場面

-ユーザーの代理でアクセスする場合 → 認可コードフローを使用
-フロントエンドアプリケーション → PKCE を使用
-ユーザーの権限を使いたい場合

セキュリティ上の考慮事項

!client_secret の安全な管理が必須
!ユーザーコンテキストがないため、クライアント単位でのアクセス制御になる
!トークンの有効期限を短く設定する
!スコープを最小限に制限する（最小権限の原則）
!client_secret のローテーションを定期的に行う