Meta Quest構成証明API

• 正規のアプリバイナリ: Meta Horizonストアで認められた、変更の加えられていないアプリバイナリを使用しているかどうかを判断
• 正規のMetaデバイス: 変更や改ざんの加えられていないMeta Questヘッドセットでアプリが動作しているかどうかを判断

• ノンスの生成 - アプリサーバーがchallenge_nonceを生成し、アプリクライアントに送信します。このチャレンジノンスは、プロセスの重要な要素です。これはサーバー側で生成されるものであり、リプレイ攻撃を防ぐためには同じチャレンジノンスを再利用しないことが重要です。
• セキュリティシグナル - 構成証明APIは必要なセキュリティシグナルを収集し、Meta構成証明サーバーに転送します。ステップ3とステップ4にあるプロセスは、一点鎖線で示されています。これは、アプリクライアントが直接関与することなく、これらのステップがバックグラウンドで発生することを意味します。
• トークンの生成 - 受け取ったセキュリティシグナルに基づいて、構成証明サーバーが構成証明トークンを生成します。プロセスのセキュリティと信頼性を強化するため、このトークンには構成証明サーバーによって暗号化方式で署名されます。
• トークンの受け取り - 構成証明APIが構成証明トークンを受け取り、アプリクライアントに送信します。
• サービスリクエスト - Meta Questアプリが構成証明トークンを受け取ると、認証を受けるために、このトークンを独自のアプリサーバーに送り返す必要があります。認証プロセスは、セキュリティ強化のため、クライアント側ではなくサーバー側で実施されます。アプリクライアントは、サービスリクエストに構成証明トークンを含めて、アプリサーバーに送信します。ここでは、アプリサーバーがこのトークンを使って、クライアントが改ざんされていないかどうかを判断することが極めて重要になります。
• トークン認証リクエスト - サービスリクエストを受け取ると、アプリサーバーはトークン認証リクエストを構成証明サーバーに送信します。
• トークンの認証 - 構成証明サーバーはトークンを検証し、その結果をトークンのクレームとともにアプリサーバーに送り返します。トークンが無効な場合はエラーメッセージが送信され、有効な場合はトークンのクレームが送信されます。
• サービスの提供 - アプリサーバーはトークンの認証結果をもとに、アプリクライアントに対してサービスを提供するかどうかを決定します。トークンが正常に認証されると、サーバーがアプリクライアントからのサービスリクエストに応じます。

1. Unity Asset StoreでMeta XRオールインワンSDK⁠に移動し、[Add to My Assets (マイアセットに追加)]を選択します。構成証明APIを使用するには、v55以降のオールインワンSDKとMeta Horizon OSシステムの両方が必要です。
2. Meta XRオールインワンSDKをUnityアセットに追加した後、[Open in Unity (Unityで開く)]を選択すると、Unityの[Package Manager (パッケージマネージャ)]で統合プロセスを実行できます。
3. パッケージマネージャで、[Meta XR All-in-One SDK (Meta XRオールインワンSDK)] > [Install (インストール)]を選択します。

using Oculus.Platform;
using System.Security.Cryptography;

// The "challenge_nonce" parameter must be a non-wrapping Base64URL-encoded
// string, formed from a random byte array by the application server.
string GetChallengeNonceFromAppServer()
{
    byte[] randomBytes = new byte[16];
    using (RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider())
    {
        rng.GetBytes(randomBytes);
    }
    // Convert to Base64 string
    string base64Nonce = Convert.ToBase64String(randomBytes);
    // Replace standard Base64 characters to make it URL safe
    string challenge_nonce = base64Nonce.Replace('+', '-').Replace('/', '_');
    // The length of the challenge_nonce must range from 22 to 172 characters.
    return challenge_nonce;
}

void SampleCode()
{
    string challenge_nonce = GetChallengeNonceFromAppServer();
    Debug.Log("Calling the Attestation API");
    DeviceApplicationIntegrity
        .GetIntegrityToken(challenge_nonce)
        .OnComplete(GetIngegrityTokenCallback);
}

void GetIngegrityTokenCallback(Message<string> msg)
{
    if (msg.IsError)
    {
        Debug.Log("GetAttestationToken() Error: " + msg.GetError().Message);
    }
    else
    {
        String attestation_token = msg.Data;
        // Send the Attestation token to the app server for token verification
    }
}

1. Meta Questの開発者ダッシュボード⁠に移動します。
2. アプリを選択します。
3. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。
4. [App Credentials (アプリ認証情報)] のセクションで、アクセストークンをコピーします。アクセストークンはOC|App_ID|App_Secretの形式を使用します。
5. 次のエンドポイントで、{access_token}パラメーターをそのアクセストークンに置き換え、{attestation_token}パラメーターを検証対象のアプリクライアントから受け取った構成証明トークンに置き換えます。

    https://graph.oculus.com/platform_integrity/verify?token=<attestation_token>&access_token=<access_token>
6. 構成証明トークンの認証に成功すると、構成証明サーバーから成功を知らせる以下のような応答が届きます。

    {
      "data": [
        {
            "message": "success",
            "claims": "<base64url_encoded_claim>"
        }
      ]
    }
   
   {base64url_encoded_claim}は、認証済み構成証明トークンのクレームを表すBase64URLエンコード文字列です。
   構成証明トークンの署名が無効な場合、構成証明サーバーは以下のような応答を返します。

    {
      "data": [
        {
            "message": "invalid signature"
        }
      ]
    }
   
   この応答は、無効な署名により、構成証明トークンを認証できなかったことを示しています。アプリサーバーは、不正利用されている可能性があるものとしてクライアントを扱う必要があり、アプリクライアントからのサービスリクエストを却下することもできます。アプリのセキュリティを維持するためには、アプリサーバーがこうしたシナリオを適切に処理することが重要です。
   構成証明トークンは、デフォルトで24時間有効です。トークンの検証プロセス中に、トークンの有効期限が切れた場合、構成証明サーバーは以下のエラーメッセージを返します。

    {
      "data": [
        {
            "message": "token expired"
        }
      ]
    }
   
   パフォーマンスのオーバーヘッドとAPIの呼び出し頻度を最小限に抑えるため、アプリクライアントは構成証明トークンを一定期間キャッシュすることができます。ただし、有効期限切れのトークンが使用されないよう、この期間はトークンの有効期間よりも短くする必要があります。このキャッシュ戦略により、安全な通信の確保とアプリの効率的なパフォーマンス維持を最適なバランスで実現できます。

{
  "request_details": {
    "exp": 1684606153,
    "nonce": "JMxMPp1H6kCxGzPRsjKFLw==",
    "timestamp": 1684519753
  },
  "app_state": {
    "app_integrity_state": "NotEvaluated",
    "package_cert_sha256_digest": [
      "c8a2e9bccf597c2fb6dc66bee293fc13f2fc47ec77bc6b2b0d52c11f51192ab8"
    ],
    "package_id": "com.example.name123",
    "version": "1"
  }
  "device_state": {
    "device_integrity_state": "NotTrusted",
    "unique_id": "cd81cd7e7e0525f99442ab6392117e89759e8872852de0495aa58f22bd8a1253",
  }
}

• timestamp: トークンが作成されたUTC時刻(秒単位)です。
• exp: トークンの有効期限を示すUTC時刻で、デフォルトではトークンの作成後24時間に設定されています。
• : DeviceApplicationIntegrity.GetIntegrityToken(string challenge_nonce) APIを呼び出す際に呼び出し元が提供したchallenge_nonceと全く同じ文字列です。

• app_integrity_state: このフィールドには、Meta QuestアプリがMeta Questストアを通じて正規にインストールされたかどうかが示されます。正規のインストールの場合はStoreRecognized、不正インストールの場合はNotRecognized、識別不能なアプリの場合はNotEvaluatedが返されます。
• package_cert_sha256_digest: このフィールドには、すべてのパッケージ証明書の署名⁠に使われたSHA2-256ハッシュが表示されます。アプリ開発者がアプリパッケージへの署名に使用する証明書が複数ある(証明書チェーンがある)場合、ハッシュも複数表示されることがあります。アプリサーバーは、返されたハッシュと既知の証明書の署名ハッシュを比較することができます。
• package_id: このフィールドには、アプリ開発者が提供したパッケージの名前が表示されます。パッケージ名の形式は、com.example.name123です。
• version: このフィールドには、アプリ開発者が提供したパッケージのバージョンが表示されます。

• device_integrity_state: このフィールドは、Meta Questデバイスの信頼性に関するインサイトを提供します。指定可能な値は次の3つです。
  • Advanced: デバイスのブートローダーがロックされており、起動されたAndroid OSは有効なシステムイメージであり、システムへの不正アクセスや改ざんの兆候は確認されていない。
  • Basic: デバイスのブートローダーはロックされており、起動されたAndroid OSは有効なシステムイメージとなっているが、他のシステム整合性チェックの一部に失敗している。これは、起動以降にシステムが侵害された可能性を示唆するもので、例えばルート化されている場合などが該当します。
  • NotTrusted: デバイスのブートローダーがロック解除されているか、起動したAndroid OSイメージが有効なシステムイメージではない。
• unique_id: この識別子はアプリごとにユニークであり、同じデバイスの異なるアプリが確実に別個のIDを持つようにします。ランダムな文字列として生成され、特定のアプリのためにデバイスをユニークに識別するものとなります。ユーザーのプライバシーを保護し、長期にわたるデバイストラッキングを阻止するため、unique_idは30日ごとに更新されます。しかし、このほぼ1か月の期間内であれば、アプリはこのIDをハードウェア禁止行為検出のために活用することができます。

• 不正な修正とセキュリティ侵害: 構成証明APIにより不正に修正されたアプリ(海賊版アプリなど)が検出されたかどうかを判断します。
• 繰り返される重度の悪用: 特定のMeta Questデバイスから繰り返される重度の悪用が確認されたかを判断します。

1. デバイスは疑似のunique_idによって識別されます。これは現在の構成証明トークンのdevice_stateセクションから取得されたものです。
2. アプリサーバーからMeta構成証明サーバーに、デバイスのunique_idとブロック期間が指定されたサーバー間リクエストを送信します。
3. リクエストに成功すると、Meta構成証明バックエンドによりデバイスが「アプリをブロック」としてマークされます。
4. このブロックステータスを反映して、その後のデバイスの構成証明トークンにはdevice_banセクションが組み込まれます。

1. アプリサーバーで構成証明トークンが受信されると、トークンにdevice_banセクションis_banned:trueがあるかどうかがチェックされます。
2. 条件が満たされている場合、ブロックの施行方法を決定します。

1. 開発者ダッシュボード⁠に移動して、アプリを選択します。
2. 左側のメニューから、[Requirements (要件)] > [Data Use Checkup (データの使用状況の確認)]に移動します。
3. [Device Ban (デバイスのブロック)]まで下にスクロールし、右側の[Add (追加)]をクリックします。
4. フォームに入力し、[Submit (送信)]をクリックします。
5. アプリレビュー担当者がリクエストを承認すると、その機能を利用できるようになります。

• デバイスをブロックする
• 既存のデバイスブロックの残り時間を更新する
• 既存のデバイスのブロックを解除する
• 特定のデバイスが現在ブロックされているかどうかを確認する
• 指定されたブロックが現在アクティブかどうかを確認する
• アプリのすべてのアクティブなブロックリストを取得する

{
  "request_details": {
    "exp": 1684606153,
    "nonce": "JMxMPp1H6kCxGzPRsjKFLw==",
    "timestamp": 1684519753
  },
  "app_state": {
    "app_integrity_state": "StoreRecognized",
    "package_cert_sha256_digest": [
      "c8a2e9bccf597c2fb6dc66bee293fc13f2fc47ec77bc6b2b0d52c11f51192ab8"
    ],
    "package_id": "com.example.name123",
    "version": "1"
  }
  "device_state": {
    "device_integrity_state": "Advanced",
    "unique_id": "442ab6392117e89759e8872852de0495aa58f22bd8a1253123123",
  }
}

{
  "request_details": {
    "exp": 1684606153,
    "nonce": "JMxMPp1H6kCxGzPRsjKFLw==",
    "timestamp": 1684519753
  },
  "app_state": {
    "app_integrity_state": "StoreRecognized",
    "package_cert_sha256_digest": [
      "c8a2e9bccf597c2fb6dc66bee293fc13f2fc47ec77bc6b2b0d52c11f51192ab8"
    ],
    "package_id": "com.example.name123",
    "version": "1"
  }
  "device_state": {
    "device_integrity_state": "Advanced",
    "unique_id": "442ab6392117e89759e8872852de0495aa58f22bd8a1253123123",
  }
  "device_ban": {
    "is_banned": true
    "remaining_ban_time": 34 days
  }
}

1. トークンの認証を使って構成証明トークンをクエリし、トークンのクレームの「device_state」セクションで「unique_id」を取得します。
2. 開発者ダッシュボード⁠に移動して、アプリを選択します。
3. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。
4. [App Credentials (アプリ認証情報)]のセクションで、アクセストークンを取得します。アクセストークンの形式は、OC/App_ID/App_Secretです。
5. 次のエンドポイントで、以下のように書き換えます。

• unique_idに、ステップ1に示す構成証明トークンにある疑似の固有IDを設定。
• is_bannedに、デバイスをブロックする場合はtrueを、ブロックしない場合はfalseを設定。
  注: このパラメーターは、is_bannedの設定がfalseの場合でも必要ですが、無視されます。
• remaining_time_in_minuteに、デバイスのブロック時間として0～52560000 (100年)の整数値を設定。
• access_tokenパラメーターに、ステップ5に示すアクセストークンを設定。

 https://graph.oculus.com/platform_integrity/device_ban?method=POST&unique_id=<unique_id>&is_banned=<is_banned>&remaining_time_in_minute=<remaining_time_in_minute>&access_token=<access_token>

{
   "message": "Success",
   "ban_id": "NjIxMzI3MTc0MTgzMzkzNw"
}

{
   "error": {
      "message": "There is no record of this Unique ID. Please check that the Unique ID matches what is given in the Attestation Token and try again. Note that Unique IDs will change every 30 days for each application and device, make sure the Unique ID is up to date.",
      "type": "OCApiException",
      "code": 1,
      "error_data": {


      },
      "error_subcode": 1614026,
      "fbtrace_id": "AUhV19OFsDqs6gTXn7zVybm"
   }
}

{
   "error": {
      "message": "The App ID of the Access Token does not match the Unique ID, please check the Unique ID/Access Token and try again",
      "type": "OCApiException",
      "code": 1,
      "error_data": {


      },
      "error_subcode": 1614027,
      "fbtrace_id": "AHBbS8rEDcgajcgpQcqtVO1"
   }
}

{
   "error": {
      "message": "The Remaining Time In Minute field is invalid. Please check that the time inputted is between 0 and 52560000.",
      "type": "OCApiException",
      "code": 1,
      "error_data": {


      },
      "error_subcode": 1614028,
      "fbtrace_id": "AtFBCvCIb4IXSGvvc4GudY8"
   }
}

1. Meta Quest開発者ダッシュボード⁠に移動して、アプリを選択します。
2. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。

3. [App Credentials (アプリ認証情報)] のセクションで、アクセストークンをコピーします。これは**OCという形式になっています。

   App_ID

   App_Secret**.

4. 以下のエンドポイントで、<access_token>パラメーターを、ステップ3で取得したアクセストークンに置き換えます。

https://graph.oculus.com/platform_integrity/device_ban_ids?access_token=<access_token>

{
   "data": [
      {
         "message": "Success",
         "all_ban_ids": [
    {
               "ban_id": "MTI0MjQ3MTc0MDk2NTYwNg",
               "creation_date": "2025-05-27"
            },
            {
               "ban_id": "NTgyOTAyMTc0MDk2NTgyNQ",
               "creation_date": "2025-05-09"
            },
            {
               "ban_id": "ODUyMTk1MTc0NjY1MjUzMw",
               "creation_date": "2025-05-07"
            }
         ]
      }
   ],
   "paging": {
      "cursors": {
         "before": "QVFIUmcwb3MtZAkhkWUhjZAElXQ2tHUXMwbjdjRi1NeUg5aWlIN3liSzZAfN1FmdnVIRkhmSVU3OUtpQ3FweUp3NE1TYWJob3k1NGIzeDRIdjdlMXRZAcWtyWGxn",
         "after": "QVFIUmcwb3MtZAkhkWUhjZAElXQ2tHUXMwbjdjRi1NeUg5aWlIN3liSzZAfN1FmdnVIRkhmSVU3OUtpQ3FweUp3NE1TYWJob3k1NGIzeDRIdjdlMXRZAcWtyWGxn"
      }
   }
}

• 表示されているban_idは、すべてアプリで有効になっています。各ブロックのban_idは変更されることはなく、有効期限もありません。ブロックが解除された場合、またはブロックの有効期限が切れた場合、ban_idは削除され、以降このエンドポイントから返されなくなります。
• creation_dateフィールドは、元のブロック作成リクエストの日時(世界標準時)を返します。
• ページングセクションでは、1ページに表示できる数を超えるブロックがある場合、次のページのban_idに関する情報が表示されます。表示可能なban_idの上限は500件です。ブロックの数に上限はありませんが、このエンドポイントに表示される数には制限があります。ページングの上限に達すると、以下のようにban_id の次のページへのURLリンクが表示されます。ページングの上限に達しない場合、[next (次)]フィールドは省略されます。

{
   "data": [
      {
         "message": "Success",
         "all_ban_ids": [
    {
               "ban_id": "MTI0MjQ3MTc0MDk2NTYwNg",
               "creation_date": "2025-05-27"
            },
            .
		 .
		  <500 ban_ids here>
		 .
		 .
		 .
         ]
      }
   ],
   "paging": {
     "cursors": {
        "before": "QVFIUkIxLS1XNDhSdHJFQXlELXplbnZAINnd6cmc5ZAkhEOVJPU3ViR1F4TFQ4V3N3NWwxV1Y0T05rLWk4NWhKM2dGY2d2aGpaZAERfd0lSOXRYejdWbTJYYUhB",
        "after": "QVFIUjlMcGJuRGxHUFRjT1lLOS04cGdRZAHpPSDFBQnA0aEJOZA3hmeDVaWEVSdXozM2FkOV9jVFhoVy1Jb08xRzlZAOVlROWNvTlNxMUpveUphZAmEzY2ZAHNFJ3"
     },
     "next": "https://graph.oculus.com/platform_integrity/device_ban_ids?access_token=<access_token>&pretty=1&limit=500&after=QVFIUjlMcGJuRGxHUFRjT1lLOS04cGdRZAHpPSDFBQnA0aEJOZA3hmeDVaWEVSdXozM2FkOV9jVFhoVy1Jb08xRzlZAOVlROWNvTlNxMUpveUphZAmEzY2ZAHNFJ3"
  }
}

1. 元のブロックリクエストからban_idを取得するか、すべての有効なデバイスブロックIDを取得することで、すべての有効なデバイスブロックのban_idを取得します。
2. 開発者ダッシュボード⁠に移動して、アプリを選択します。
3. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。

4. [App Credentials (アプリ認証情報)]のセクションで、access_tokenを取得します。これは**OCという形式になっています。

   App_ID

   App_Secret**.

5. 次のエンドポイントで、以下のように書き換えます。
   • <ban_id>に、ステップ1で取得したban_idを設定。
   • <is_banned>をtrueに設定するとブロックを適用し、falseに設定するとブロックを解除します。
   • <remaining_time_in_minute> に、デバイスのブロック時間を分単位で示す0～52560000 (100年)の整数値を設定。is_bannedがtrueに設定されている場合にのみ必要となります。
   • <access_token>に、ステップ4に示すアクセストークンを設定。

https://graph.oculus.com/platform_integrity/device_ban?method=POST&ban_id=<ban_id>&is_banned=<is_banned>&remaining_time_in_minute=<remaining_time_in_minute>&access_token=<access_token>

{
   "message": "Success",
   "ban_id": ""
}

{
   "message": "Success",
   "ban_id": "NjIxMzI3MTc0MTgzMzkzNw"
}

{
   "error": {
      "message": "There is no record of this ban_id. Please check the ban_id and try again. If you don't know the specific ban_id, query the Device Ban IDs endpoint to see a list of all the ban_ids currently active for your application.",
      "type": "OCApiException",
      "code": -1,
      "error_data": {


      },
      "error_subcode": 1614033,
      "fbtrace_id": "AzBdHW5FhJ8xtfLLzQr90Gz"
   }
}

​​{
   "error": {
      "message": "The App ID of the Access Token does not match the Ban ID, please check the Ban ID/Access Token and try again",
      "type": "OCApiException",
      "code": -1,
      "error_data": {


      },
      "error_subcode": 1614036,
      "fbtrace_id": "AIp_qT4f8skiZrs1NI2xPjN"
   }
}

1. トークンの認証を使って構成証明トークンをクエリし、トークンのクレームの「device_state」セクションで「unique_id」を取得します。
2. 開発者ダッシュボード⁠に移動して、アプリを選択します。
3. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。

4. [App Credentials (アプリ認証情報)]のセクションで、access_tokenを取得します。これは**OCという形式になっています。

   App_ID

   App_Secret**.

5. 次のエンドポイントで、以下のように書き換えます。
   • <unique_id>に、ステップ1に示す構成証明トークンにある疑似の固有IDを設定。
   • <is_banned>をtrueに設定するとブロックを適用し、falseに設定するとブロックを解除します。
   • <remaining_time_in_minute> に、デバイスのブロック時間を分単位で示す0～52560000 (100年)の整数値を設定。is_bannedがtrueに設定されている場合にのみ必要となります。
   • <access_token>に、ステップ4に示すアクセストークンを設定。

https://graph.oculus.com/platform_integrity/device_ban?method=POST&unique_id=<unique_id>&is_banned=<is_banned>&remaining_time_in_minute=<remaining_time_in_minute>&access_token=<access_token>

{
   "message": "Success",
   "ban_id": ""
}

{
   "message": "Success",
   "ban_id": ""
}

{
   "message": "Success",
   "ban_id": "NjIxMzI3MTc0MTgzMzkzNw"
}

1. 元のブロックリクエストからban_idを取得するか、(このガイドの)手順に従って、すべての有効なデバイスブロックのban_idを取得します。
2. Meta Quest開発者ダッシュボード⁠に移動して、アプリを選択します。
3. 左側のナビゲーションで、[Development (開発)] > [API]を選択します。

4. アプリ認証情報セクションで、アクセストークン(形式は**OC)をコピーします。

   App_ID

   App_Secret**.

5. 次のエンドポイントで、以下のように書き換えます。
   • <ban_id>パラメーターに、ステップ1で取得した**ban_id**を設定。
   • <access_token>パラメーターに、ステップ4に示すアクセストークンを設定

 https://graph.oculus.com/platform_integrity/device_ban_status?unique_id =<unique_id>&access_token=<access_token>

{
   "data": [
      {
         "message": "Success",
         "is_banned": true,
         "remaining_time_in_minute": 12
      }
   ]
}

{
   "error": {
      "message": "There is no record of this Unique ID. Please check that the Unique ID matches what is given in the Attestation Token and try again. Note that Unique IDs will change every 30 days for each application and device, make sure the Unique ID is up to date.",
      "type": "OCApiException",
      "code": 1,
      "error_data": {


      },
      "error_subcode": 1614026,
      "fbtrace_id": "AUhV19OFsDqs6gTXn7zVybm"
   }
}

{
   "error": {
      "message": "The App ID of the Access Token does not match the Unique ID, please check the Unique ID/Access Token and try again",
      "type": "OCApiException",
      "code": 1,
      "error_data": {


      },
      "error_subcode": 1614027,
      "fbtrace_id": "AHBbS8rEDcgajcgpQcqtVO1"
   }
}

• Device Integrity State Bypass: これはデフォルトで有効になっています。これが有効になっている場合、Metaの内部テストデバイスでは、構成証明トークンのdevice_state内のdevice_integrity_stateが常にAdvancedに設定されます。これは、アプリサーバーがNotTrustedデバイス上でサービスをブロックする場合に特に便利です。このバイパス機能を使えば、アプリをMetaのデバイス上でシームレスにテストできるため、Metaの内部テストチームによる効率的なサポートが可能になります。これは特に、予備ビルドリリースの評価において有効です。
• Token Expiration Duration: この設定により、構成証明トークンの寿命が決まります。デフォルトの有効期限は24時間です。期間が短いと、デバイスやアプリの不正アクセスを検出するための所要時間が短縮されてセキュリティは強化されますが、必要になる構成証明のチェックの頻度は高くなります。逆に期間が長いと、アプリへの負荷は減りますが、侵害された場合に不正アクセスが拡大するリスクが高くなります。

• exp (トークン有効期限)が24時間以内である
• nonceが構成証明APIリクエストで使われるchallenge_nonceと同じである
• timestampが最新である(数分以内)
• app_integrity_stateはパッケージがHorizonストアからインストールされていることを示している
• package_cert_sha256_digestハッシュが想定どおりである
• device_integrityがAdvancedまたは少なくともBasicである

  challenge_nonceに一意の要素を含める
  ​​​リプレイ攻撃を防ぐため、チャレンジノンスは一度だけ使い、一意の要素を含める必要があります。
• サーバーサイドのバックエンドで、悪意のあるユーザーが予測できない、グローバルに一意の値を作成する。これは、暗号的に安全な新しいランダムな番号か、取引IDなどの既存のユニークなトークンになります。この値をサーバー側のユーザーセッションに保存し、クライアントアプリにも送信して、challenge_nonceとして使用されます。
• 検証済み構成証明クレームを受け取ったら、クレーム内のノンスが保管済みのchallenge_nonceと一致することを確認する。保存された一意の値は、単一の構成証明クレームの検証にのみ使われるため、破棄してください。

  challenge_nonceに機密性の高いリクエストをバインドする
  ​​​構成証明APIは、機密性の高い取引を保護するために使うと最も価値が高まります。そのようなアクションを特定し、構成証明APIを使って保護することで、ユーザーはアクションが実行される前に課題を課されるかブロックされます。​​​これを実現するために、以下のような大まかな設計を検討してください。
• サーバーサイドのバックエンドは、固有の値を生成して(前のセクションに従って)、クライアントアプリに送信し、その記録を保持する。
• クライアント側のアプリは、バックエンドに高額の取引リクエストを送信する準備をしながら、重要なリクエストパラメーターのダイジェストを計算する。
  • 例: リクエストの詳細(アクセストークンCookie、ユーザーID、取引データなど)を含む、シリアル化されたリクエストフォーマット
• このハッシュは、バックエンドからクライアントに送信されるユニークな値と組み合わされ、構成証明APIのchallenge_nonceとして使用される。
• クライアント側のアプリは、構成証明トークンをこのリクエストの一部として含めた上で、高価値のリクエストをバックエンドに送信する。
• サーバーサイドのバックエンドがこのリクエストを受け取ると、構成証明トークンがMetaサーバーに送信され、検証が行われる。構成証明トークンの検証後、Metaサーバーはクレームの詳細を返す。
• バックエンドは、受信したリクエストのパラメーターと保存された一意の値を組み合わせて、期待されるノンスを計算し、構成証明クレームのノンスと比較する。これらが異なる場合、構成証明リクエストが改ざんされた可能性があります。

  バイナリブロックの代わりにアカウント制限を選択する
  ​​​構成証明のクレームを検証できないエラーがある場合や、不正利用の可能性があることを示している場合は、単にユーザーを記録したりブロックしたりするのではなく、さまざまな結果を返すようにします。これにより、システムを迂回することが困難になります。例えば、ユーザーが不正使用の可能性があるとフラグされた場合、アクセスを許可するものの利用可能なアクションに制限を課すか、CAPTCHAのような強化認証を強制することを検討してください。