クライアントID・クライアントシークレットの管理

クライアントID シークレット認証アプリ登録

開発者アプリには、アプリを識別するクライアントIDと、アプリを認証するクライアントシークレットが発行されます。クライアントIDは公開しても問題のない識別子ですが、クライアントシークレットはパスワードと同じ扱いが必要な機密情報です。この記事では、それぞれの確認方法、保管のルール、漏えいが疑われるときの対応、複数環境での運用を説明します。

確認する場所

ビジネスアカウント詳細のメニューから「開発者アプリ」を開き、対象のアプリを開きます。
「認証情報」の欄に、クライアントID（app_ で始まる文字列）がいつでも表示され、コピーできます。
クライアントシークレット（英数字32文字）は、アプリの作成直後と再生成の直後に一度だけ表示されます。レシートローラーはシークレットをハッシュ化して保存しているため、後から表示し直すことはできません。

公開クライアント (モバイルアプリ) として登録したアプリでは、シークレットは使わず、表示もされません。認可には PKCE を使います。

クライアントIDとシークレットの違い

項目	クライアントID	クライアントシークレット
公開してよいか	よい	いけない
役割	アプリの識別（認可URLの `client_id`）	アプリの認証（トークンエンドポイントの `client_secret`）
配布するアプリ・ブラウザのコード	含めてよい	含めない（サーバー側だけ）
URL	含めてよい	含めない（リクエスト本文で送る）

保管のルール

環境変数やシークレット管理サービス（Azure Key Vault、AWS Secrets Manager など）に保管します。
ソースコードに直接書かず、Git リポジトリに含めないでください。
本番・ステージング・開発でアプリを分け、シークレットも別にします。
本番のシークレットを読めるのは本番環境のサービスだけにします。
ログやエラー出力に含めないでください。

漏えいが疑われるとき

すぐにシークレットを再生成してください。再生成できるのはビジネスアカウントのオーナーです。

アプリの詳細画面の「認証情報」で「再生成」を押し、確認ダイアログで進めます。
新しいシークレットが一度だけ表示されるので、安全な場所に保管します。
古いシークレットはその場で無効になります。猶予期間はないため、本番環境の設定をすぐに新しいシークレットへ入れ替えてデプロイしてください。入れ替えるまでの間、トークンの取得と更新は 401 invalid_client になります。
再生成しても、発行済みのアクセストークンとリフレッシュトークンは取り消されません。トークンも漏れた可能性がある場合は、POST /api/v1/auth/revoke で取り消すか、連携先ビジネスアカウントのオーナーに「連携アプリ」から連携を取り消してもらってください。

複数環境での運用

本番用と開発用のアプリは必ず分けて登録してください。1つのアプリに登録できるリダイレクトURIは1つなので、環境ごとに URI が違う場合も分ける必要があります。どのアプリのクライアントIDも app_ で始まるため、アプリ名に環境を入れておくと取り違えを防げます。

マイアプリ (prod)
  → クライアントID: app_…（本番用）
  → シークレット: 本番のシークレット管理サービス

マイアプリ (dev)
  → クライアントID: app_…（開発用）
  → シークレット: 開発環境の環境変数