App Check ライブラリをアプリに追加した後、App Check の適用を有効にする前に、既存の正規ユーザーを中断しないように対策を行う必要があります。
その判断に使用できる重要なツールは、App Check リクエストの指標です。プロジェクト全体または個々の OAuth クライアントの指標を表示できます。
プロジェクトの App Check リクエストの指標を表示するには、Firebase コンソールで [App Check] セクションを開き、[Google Identity for iOS] セクションを開きます。例:
特定の OAuth クライアントの App Check リクエストの指標を表示するには、Firebase コンソールの [OAuth クライアント] ページを開き、クライアントに対応するセクションを開きます。
リクエストの指標は 4 つのカテゴリに分類されます。
確認済みリクエストは、有効な App Check トークンを含むリクエストです。App Check の適用を有効にすると、このカテゴリのリクエストのみが成功します。
古いクライアント リクエストは、App Check トークンのないリクエストです。これらのリクエストは、アプリに App Check が追加される前の古いバージョンの Firebase SDK から送信されたリクエストである可能性があります。
送信元が不明なリクエストは、App Check トークンのないリクエストで、Firebase SDK から送信されていない可能性があります。これには、盗まれた API キーで行われたリクエストや、Firebase SDK を使用せずに行われた偽造リクエストなどが該当します。
無効なリクエストは無効な App Check トークンを含むリクエストです。アプリになりすますために権限のないクライアントから送信された可能性があります。また、エミュレートされた環境から送信された可能性もあります。
アプリがこのカテゴリのどれに分類されるのかにより、適用を有効にするかどうかを判断する必要があります。その場合、以下のガイドラインに従ってください。
最近のリクエストのほとんどが検証済みのクライアントからのものである場合は、適用を有効にして、認証エンドポイントの保護を開始することを検討してください。
最近のリクエストの大部分が古いクライアントからのものである場合は、ユーザーの混乱を避けるため、アプリを更新するユーザーが増えるまで適用を有効にしません。リリースされたアプリに App Check を適用すると、App Check SDK と統合されていない以前のバージョンのアプリが破損します。
アプリをまだリリースしていない場合は、古いクライアントが存在しないため、App Check の適用をすぐに有効にします。
次のステップ
App Check がユーザーに与える影響を理解し、続行する準備ができたら、App Check の適用を有効にします。