クライアントID・クライアントシークレットの管理
クライアントID
シークレット
認証
アプリ登録
この記事の対象
レシートローラーのアプリ登録後、クレデンシャルを安全に管理したい開発者向けです。
レシートローラーのアプリ登録後、クレデンシャルを安全に管理したい開発者向けです。
レシートローラーのOAuth認証では、アプリごとに発行されるクライアントIDとクライアントシークレットのペアを使います。クライアントIDは公開しても問題ない識別子ですが、クライアントシークレットはパスワード相当の機密情報です。
取得方法
- 開発者ポータル → アプリ → 対象アプリを開く
- 「クレデンシャル」タブ
- クライアントIDが表示されている(コピー可)
- クライアントシークレットは初回発行時のみ表示。以降は再生成が必要
クライアントIDとシークレットの違い
| 項目 | クライアントID | クライアントシークレット |
|---|---|---|
| 公開可否 | 公開可 | 非公開 |
| 役割 | アプリの識別 | アプリの認証 |
| クライアント側コード | 含めてOK | 絶対NG(サーバー側のみ) |
| URLパラメータ | 含めてOK | 絶対NG |
保管ルール
- 環境変数またはシークレット管理サービス(AWS Secrets Manager、Azure Key Vault、GCP Secret Manager 等)に保管
- ソースコードに直書きしない(gitに混入するとリポジトリ流出時に終わり)
- 本番/ステージング/開発で別シークレットを使う
- アクセス権限は本番環境のサービスアカウントのみに付与
- ログ・エラー出力に含めない
漏えい時の対応
緊急時の手順:シークレット漏えいが疑われたら、すぐに開発者ポータルで再生成してください。古いシークレットは無効化されます。
- 開発者ポータル → アプリ → クレデンシャル → 「シークレットを再生成」
- 新シークレットを安全に保管
- 本番環境の環境変数を更新してデプロイ
- 旧シークレットを「即時失効」または「24時間後失効」を選択
- 監査ログで不正利用がなかったか確認
複数環境での運用
本番アプリと開発アプリを必ず分けて登録することを推奨します。1つのアプリに複数環境を相乗りさせると、開発時の不具合で本番ユーザーに影響が出るリスクがあります。
本番アプリ:MyApp Production → クライアントID: prod_xxx → シークレット: 本番のシークレット管理サービス 開発アプリ:MyApp Dev → クライアントID: dev_xxx → シークレット: 開発者各自の.env
関連ガイド
公開日: 2026-04-27
更新日: 2026-04-27
カテゴリ
タグ
API (8)
Webhook (8)
api (6)
oauth (5)
トラブル (5)
OAuth (4)
getting-started (4)
アプリ登録 (4)
app-registration (3)
webhook (3)