tencent cloud

Tencent Cloud EdgeOne

ドキュメントTencent Cloud EdgeOneDDoSとWeb保護Bot管理クライアント認証統合ガイドステップ2：クライアント認証の統合モバイル端末統合に関する参考情報

モバイル端末統合に関する参考情報

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-15 18:07:47
AI翻訳

概要

クライアント認証は、各APIリクエストに有効な認証トークンが必ず付与されることを保証し、リクエストが信頼済みモバイルアプリケーションから発信されたことを検証することで、悪意のあるリクエストを効果的に防御します。Web側やWebView側の自動遮断メカニズムとは異なり、モバイルクライアントの統合では、リクエストの送信、認証トークンの取得と付与、およびサーバーチャレンジへの応答を実現するために、開発者がアプリケーション層で対応を行う必要があります。

互換性

EdgeOne クライアント認証 SDK は以下のモバイル端末をサポートします：
iOS 11以上のバージョンのオペレーティングシステム。
Android 5.0 (API level 21) 以上のバージョンのオペレーティングシステム。

モバイルSDK動作メカニズムの概要

EdgeOne クライアント認証 SDK は、iOS または Android 環境において、その中核となる動作メカニズムがクライアントアプリケーション、SDK、認証サービス、および EdgeOne 間の連携に基づいて展開されます。開発者がアプリケーションコード内で SDK インターフェースを能動的に呼び出すことにより、完全な認証フローが実現されます。
説明：
開発者は、コード内で HTTP 428 レスポンスを明示的に処理し、SDK を呼び出して認証チャレンジを実行し、取得したトークンを後続のリクエストに付与する必要があります。SDK は認証ロジックの実行とトークンの生成・管理を担当しますが、リクエストの送信、レスポンスの取得、およびリトライロジックはアプリケーション層で実装する必要があります。
以下はその主な動作原理です：
1. API リクエストの開始： モバイルアプリケーションは、EdgeOne によって保護されたバックエンドサービスに API リクエストを送信します。初期リクエストには認証トークンが含まれていないか、期限切れまたは無効なトークンが含まれている可能性があります。
2. EdgeOne 認証チャレンジ： EdgeOne はリクエストを受信した後、設定された認証ポリシーに基づいて検証を行います。リクエストが認証要件を満たしていない場合（例えば、トークンが不足しているか、トークンが無効である場合）、EdgeOne は HTTP 428 ステータスコードを返し、レスポンスヘッダー EO-Attest-Challenge に認証チャレンジ ID を含めます。
3. クライアントによるチャレンジ処理： モバイルアプリケーションは HTTP 428 レスポンスを受信した後、レスポンスヘッダーから EO-Attest-Challenge ID を抽出する必要があります。その後、アプリケーションは SDK の attestWithParams() インターフェースを呼び出し、このチャレンジ ID を渡します。SDK はチャレンジタイプ（例えば、Captcha、無感覚検証など）に基づいて対応する認証フローを実行します。詳細なクライアント認証フローについては、対応する製品ドキュメントを参照してください（参照：Tencent Cloud Captcha、Tencent Cloud RCE）。
4. SDK と認証サービスの連携： SDK はチャレンジ ID を受信した後、EdgeOne 認証サービスと連携し、クライアント認証プロセスを完了します。これには、WKWebView に Captcha インターフェースを表示してユーザーが操作することや、バックグラウンドでプルーフ・オブ・ワークを実行することなどが含まれる場合があります。
5. 認証トークンの取得： 認証が成功すると、SDK は有効な認証トークンを生成します。アプリケーションは、SDK が提供するインターフェース（例：getAttestationToken()）を通じてこのトークンを取得します。
6. リクエストの再送信： アプリケーションは、新しく取得した認証トークンを元の API リクエストの EO-Attest-Token HTTP ヘッダーに付与し、そのリクエストを再送信します。
7. EdgeOne によるリクエスト処理の継続： EdgeOne は、有効な認証トークン付きのリクエストを受信した後、トークンの有効性を検証し、リクエストがバックエンドサービスへ引き続き流れることを許可します。





認証資格情報Token処理フロー

認証トークンは、クライアントと EdgeOne 認証サービス間の信頼を確立するための重要な証明書です。iOS または Android アプリケーションでは、開発者は認証トークンのライフサイクル（取得、使用、更新を含む）を理解し、正しく処理する必要があります。

新しい認証資格情報Tokenの取得（または手動認証）

一部のシナリオでは、新しい認証トークンを取得するために、クライアント認証を能動的にトリガーする必要がある場合があります。例えば：
初回リクエスト前： アプリケーション起動後に保護された API へ初めてリクエストを送信する前に、初回リクエストで 428 チャレンジを受け取ることを避けるために、SDK を能動的に呼び出して認証を行うことができます。
HTTP 428 チャレンジの処理： サーバーから返された HTTP 428 ステータスコードを受信した場合、チャレンジ ID を抽出し、SDK インターフェースを呼び出して認証チャレンジを開始する必要があります。
強制認証： ビジネスロジックがユーザーに認証を強制する必要がある場合です。
SDK の attestWithParams() メソッドを呼び出すことで、認証チャレンジを開始できます。このメソッドは、チャレンジパラメータに基づいて対応する認証フローを実行し、成功後に AttestCallbackDelegate を通じて認証トークンを返します。
注意：
attestWithParams() の呼び出しが成功するたびに、SDK は認証トークンを生成または更新します。トークンをリクエストヘッダーに付与する前に、必ず再度 getAttestationToken() を呼び出して最新のトークンを取得してください。トークンデータを使用する必要があるたびに、新しいトークンデータを再取得してください。getAttestationToken() が返すトークンデータを保存または再利用しないでください。

既存の認証トークンの使用

認証トークンの取得に成功すると、SDK はそのトークンを内部にキャッシュします。トークンの有効期間（TTL）内は、このキャッシュされたトークンを繰り返し使用できるため、毎回認証チャレンジを再実行する必要はありません。アプリケーションがバックグラウンドで中断されたり、アイドル状態から復帰したりした場合でも、SDK はキャッシュされた有効なトークンを提供できます。
保護された API にリクエストを送信する際には、SDK から現在有効な認証トークンを取得し、それを HTTP リクエストの EO-Attest-Token ヘッダーに追加する必要があります。SDK は、このトークンを取得するために getAttestationToken() メソッドを提供します。

認証トークンの再取得、または期限切れ認証トークンの更新（HTTP 428チャレンジの処理）

認証トークンには有効期間があります。トークンの有効期限が切れた場合、またはその他の理由で無効になった場合、EdgeOne サーバーは HTTP 428 ステータスコードを返すことで、クライアントに新しい認証が必要であることを示します。これは、iOS および Android クライアント統合における最も重要な適応环节の一つです。
アプリケーションは、HTTP 428 レスポンスをキャプチャして処理するための堅牢なメカニズムを実装する必要があります。典型的な処理フローは以下の通りです：
1. 428 レスポンスのキャプチャ： ネットワークリクエストのコールバックで、HTTP レスポンスのステータスコードを確認します。ステータスコードが 428 の場合は、認証チャレンジが必要であることを示します。
2. チャレンジ ID の抽出： HTTP 428 レスポンスの EO-Attest-Challenge レスポンスヘッダーから認証チャレンジ ID を抽出します。これは新しい認証チャレンジを開始するための憑証です。
3. 認証チャレンジの実行： SDK の attestWithParams() メソッドを呼び出し、抽出した challengeId を渡します。認証器がユーザー操作（Captcha など）を必要とする場合、WKWebView インスタンスも提供する必要があります。
4. 新しいトークンの取得： 認証チャレンジが成功した後、getAttestationToken() を使用して、SDK が生成した最新の認証トークンを取得します。
5. リクエストの再送信： 新しいトークンを元の API リクエストの EO-Attest-Token ヘッダーに付与し、そのリクエストを再送信します。このとき、リクエストは EdgeOne の認証を通過し、正常にバックエンドサービスへ流れるはずです。

WKWebViewまたはWebViewを使用した対話型認証（およびJS認証）

一部のクライアント認証シナリオでは、認証器がユーザー操作（例：インタラクティブな Captcha）を必要とする場合や、計算集約型タスク（例：暗号化による作業証明）を実行する場合があります。このとき、EdgeOne SDK には特定の実行環境サポートが必要です。モバイルプラットフォームでは、WKWebView（iOS プラットフォーム）または WebView（Android プラットフォーム）がこれらの機能を実現するための重要なコンポーネントです。
説明：
以下では、WebView を異なるプラットフォームの対応コンポーネントの総称として使用します。すなわち、WKWebView（iOS プラットフォーム）または WebView（Android プラットフォーム）です。実際の統合プラットフォームのコンポーネント名に従って適合させてください。
認証器がインタラクティブな CAPTCHA をレンダリングする必要がある場合、または JavaScript ベースの暗号化による Proof-of-Work チャレンジを実行する必要がある場合、SDK は attestWithParams() メソッドを呼び出す際に WebView インスタンスを提供することを要求します。これは、開発者がアプリケーション内で事前に WebView インスタンスを割り当て、認証 API を呼び出す際にそれをパラメータとして SDK に渡す必要があることを意味します。

対話型認証シナリオ

一部の認証器（例えば、埋め込み型またはポップアップ型のインタラクティブ設定を使用する TC-CAPTCHA）は、インタラクティブインターフェースをレンダリングするために WebView インスタンスを必要とします。この WebView インスタンスはアプリケーション内部で Captcha ページを表示するため、正しく表示されるように事前に設定する必要があります。
埋め込み型インタラクティブ認証： Captcha インターフェースは固定ブロック形式でデバイス画面に表示されます。UI が正しく表示され、ユーザーエクスペリエンスに影響を与えないようにするために、開発者はレンダリングウィンドウのサイズ、重なり順、配置方法を事前に設定する必要があります。なお、埋め込み型認証 GUI は画面ビューに応じて拡大縮小されません。例えば、TC-CAPTCHA 埋め込み型モードでは、最適なレンダリング効果とユーザーインタラクション体験を得るために、少なくとも 300x230 ピクセルのスペースを確保することを推奨します。
ポップアップ型インタラクティブ認証： Captcha インターフェースは、認証が呼び出された際にフローティングウィンドウ形式でデバイス画面に表示されます。埋め込み型認証と同様に、レンダリングウィンドウのサイズ、重なり順、配置方法も事前に設定する必要があります。ポップアップ型認証の特徴は、画面ビューが特定のしきい値より小さい場合、ポップアップ型認証 GUI が自動的に拡大縮小され、異なる画面サイズに適応することです。例えば、TC-CAPTCHA ポップアップ型モードの初期レンダリングブロックサイズは 360x360 ピクセルです。

JavaScriptベースの認証シナリオ

一部の認証器（例えば、無感覚モードを使用する TC-CAPTCHA）は、JavaScript ランタイム環境として WebView インスタンスを必要とし、主に暗号化による作業証明（PoW）チャレンジの実行に使用されます。このシナリオでは、WebView インスタンスは JavaScript 実行サンドボックスのみを提供し、UI を可視的にレンダリングする必要はありません。したがって、渡される WebView インスタンスは可視である必要はなく、SDK もそれを UI レンダリングに使用しません。

統合の検証

EdgeOne クライアント認証 SDK をアプリケーションで安定的に動作させるために、以下の主要指標を参照して統合が成功したかどうかを判断してください（順番に検証とトラブルシューティングを行うことを推奨します）：

前の記事へ: Androidの統合手順次の記事へ: ステップ3：クライアント認証ルールを設定する

ヘルプとサポート

この記事はお役に立ちましたか？

フィードバック

キーワードで検索
    Enter keywords to search documentation