認証情報の取り扱い

最初のトークンを取得するのは始まりに過ぎません。OAuthアプリケーションが本番稼働したら、その認証情報を安全に保管し、時折ローテーションし、何か問題が起きたときには迅速に失効させられる必要があります。これはまさにセキュリティレビューが尋ねる項目です。このページでは、この3点に加えて、漏洩したトークンが実際に到達し得る範囲と、漏洩が疑われる場合の対応を扱います。

クライアントシークレットの置き場所

環境変数やシークレットマネージャー（AWS Secrets Manager、Vaultなど）に保管してください。ソース管理には決して含めず、コードと一緒にコミットされる設定ファイルにも決して含めないでください。
デスクトップアプリケーションやブラウザベースのクライアントには決して組み込まないでください。ユーザーのマシンにインストールされるものやブラウザに配信されるものは、そのバンドルを検査され得るため、そこに埋め込まれたシークレットは配布された瞬間から公開されているものとして扱う必要があります。
これこそが、Native Applicationフローがクライアントシークレットを一切発行しない理由です。このフローはデスクトップやCLIの統合向けに設計されており、シークレットを機密に保つ手段がないため、代わりにPKCE（認可コードに紐づくリクエストごとの証明）に依存します。Authorization Code + カスタムHTTPSリダイレクトフローもPKCEを使用しますが、リダイレクトハンドラーが自分で管理するサーバー上で動作する機密クライアントに限り、クライアントシークレットの追加を許可します。このフローをブラウザのみ（SPA）で実装する場合は、Nativeフローが決してシークレットを持たないのと同じ理由で、シークレットを設定しないでください。はじめに：OAuthフローの選択を参照してください。
Client Credentialsはサーバー間フローであり、常にシークレットが必要です。他のサーバーサイド認証情報と同じ規則で保管してください。

ダウンタイムなしでクライアントシークレットをローテーションする

Settings → OAuthでアプリケーションのシークレットを再生成すると、完全に置き換えられます。新旧両方のシークレットが同時に有効になる猶予期間はありません。古いシークレットを提示し続ける呼び出し元は、次のトークンまたはリフレッシュのリクエストから拒否されます。

とはいえ、ローテーションした瞬間にすべての進行中のリクエストが失敗するわけではありません。すでに発行されたアクセストークンは、それ自身のTTLが切れるまで動作し続けます（約1時間、トークンのライフサイクルを参照）。これは、そのトークンをもともと発行したシークレットにその後何が起きるかとは無関係です。新しいトークンのリクエストやリフレッシュだけが新しいシークレットを必要とします。

推奨される切り替え手順：

シークレットを再生成する。
同じ変更の中で、統合がシークレットを保存しているすべての場所（設定、シークレットマネージャー、各インスタンスやワーカー）を、それぞれが次にトークンを発行またはリフレッシュする前に更新する。
新しいシークレットで新しいトークンリクエストが成功することを確認する。

すべてのインスタンスを一斉に更新できない場合は、ローテーションを段階的なロールアウトではなく、調整されたデプロイとして計画してください。古いシークレットをまだ保持しているインスタンスは、次にトークンが必要になった時点で完全に失敗し、優雅に古いシークレットへフォールバックすることはありません。

アクセスを失効させる

アクセスを遮断する方法は2つあり、どちらも新規アクセスを止めます。

Settings → Third-party accessから個別の認可を取り消す。そのアプリケーションは、その認可を通じてトークンを更新・取得できなくなります。他のユーザーによるアプリケーションの利用には影響しません。
Settings → OAuthからOAuthアプリケーションを削除する。すべてのユーザーに対して失効します。そのアプリケーション向けに新しいアクセストークンやリフレッシュトークンは発行できなくなり、クライアントシークレットもローテーション時と同様に機能しなくなります。クライアントクレデンシャルを使用するアプリケーションの場合は、同じ操作でアプリケーションのサービスユーザーも無効化されます。

認可の取り消し、アプリケーションの削除、シークレットのローテーションのいずれも、すでに発行されたアクセストークンには影響せず、強制的に失効させることはありません。そのトークンは、元のスコープのまま、それ自身のTTLが切れるまで使用可能なものとして扱ってください。有効なトークンに何が影響し、何が影響しないかの全体像は、トークンのライフサイクルを参照してください。

漏洩したトークンが到達し得る範囲

漏洩したトークンは組織全体の漏洩を意味しません。3層のセキュリティモデルに沿って、二重に制限されています。

OAuthスコープ（レイヤー1）：発行時にトークンへ固定されます。後でアプリケーションからスコープを取り除いても、すでに発行済みのトークンは縮小されません。それは次のリフレッシュまたは再発行のタイミングで初めて反映されます。
サービスユーザーのコンテンツアクセスとロール（レイヤー2と3）：そのトークンのサービスユーザーがどのノード（組織、ディビジョン、サイト）を見ることができ、そこで何ができるか。スコープと異なり、これはトークンに固定されていません。リクエストのたびに現在の設定に照らして評価されます。

実践的な結論として、アプリケーションとそのサービスユーザーを最初から厳しく絞り込むほど、漏洩したトークンの価値は小さくなります。

漏洩が疑われる場合

以下の順序で対応してください。

クライアントシークレットを直ちにローテーションする（Settings → OAuth → 対象のアプリケーション）。これが最も速く実行できる対策であり、古いシークレットでの新しいトークンやリフレッシュのリクエストを即座に失敗させます。
今後使用するつもりがない場合、またはシークレット単体を超える侵害が疑われる場合は、OAuthアプリケーションを削除する。クライアントクレデンシャルを使用するアプリケーションの場合、これによりサービスユーザーも無効化され、新規トークンの発行が完全に止まります。
サービスユーザーのコンテンツアクセスを制限または削除する。 コンテンツ・ロールアクセス（レイヤー2〜3）はトークンに固定されるのではなくリアルタイムでチェックされるため、この対応はトークンのTTLが切れる前であっても、まだ有効な漏洩トークンが到達し得る範囲を即座に縮小します。
トークンをさらに1回分のTTLの間、有効なものとして扱う（約1時間）。上記のいずれの手順も、すでに発行済みのトークンを強制的に失効させることはありません。
新しい認証情報（新しいシークレット、または新しいアプリケーション）を発行し、通常運用を再開する前に統合側を更新する。

次のステップ

TTL、キャッシュ、リフレッシュの挙動についてはトークンのライフサイクル
スコープ、コンテンツアクセス、ロールがどう組み合わさるかについてははじめに：セキュリティモデル