認証フロー
다운로드
포커스 모드
폰트 크기
クライアント、SDK、EdgeOne エッジ、および認証サービスは、クライアント認証フローにおける主要な参加者であり、認証フローを通じて連携し、リクエスト送信元の正当性と有効性を確保し、不正アクセスや悪意のある攻撃を防止します。クライアント認証フローを把握し正しく使用することで、セキュリティリスクを効果的に低減し、サービス全体の信頼性を向上させることができます。本記事では、クライアント認証の具体的な操作手順を詳しく解説し、開発者やユーザーがクライアント認証機能を迅速に理解し効果的に使用できるように支援することで、アプリケーションの安全性と安定性を確保します。
異なるクライアントの認証フロー適応
クライアントタイプに応じて、クライアント認証は対応する認証フローを提供し、柔軟で便利な統合オプションを最大限に提供します。
認証フロー | モバイル（Android & iOS） | WebView / ブラウザ |
SDK の統合方法 | クライアント開発による統合 | 自動統合（JSインジェクション） 手動統合（フロントエンドページ適応統合） |
クライアント認証を開始します（認証資格情報を生成します）。 | 統合が必要です。 | 統合は不要です（SDKが自動的に処理します） |
チャレンジを処理します（必要に応じて認証を補充します）。 | | |
既存の認証資格情報を取得します（既存の認証を照会します）。 | | |
リクエストに認証資格情報を埋め込みます（アプリケーション認証資格情報を適用します）。 | | |
認証フロー
クライアント認証フローには以下の主要な段階が含まれます。以下では、各段階の具体的な操作方法、適用シーン、およびネットワークリクエスト面での挙動について順に説明します。
1. フロー概要
クライアント認証を能動的に開始することで、クライアントに新しい認証トークン（Attestation Token）を生成し、後続のAPIリクエストに有効な認証情報を付与できます。クライアント認証を能動的にトリガーすることで、SDKは現在のデバイスとアプリケーションに対して完全な検証を実行し、クライアントがセキュリティ要件を満たしていることを証明する暗号化された認証トークンを返します。このトークンには認証プラットフォーム、認証方式、タイムスタンプなどの情報が含まれており、人為的に改ざんすることはできません。
2. 適用シーン
クライアントアプリケーションの初期化時に、手動で新しい認証を実行します。例えば、ユーザーが初めてアプリをインストールして起動した際、クライアントは能動的に認証を開始し、信頼できる身分を確立します。
認証認証情報の有効期限が切れた後、クライアントは認証を再度実行します。ユーザーが長時間操作しなかった場合やアカウントを切り替えた場合、元の認証認証情報はすでに期限切れとなっており、クライアントは自動的に再認証を行い、セキュリティを確保します。
サービス側のチャレンジを処理する際、クライアントはチャレンジの要件に従って認証を実行します。特定の重要な操作や機密性の高いインターフェースにアクセスする場合、サービス側はクライアントに強制的な再認証を要求し、認証情報の悪用を防ぐことがあります。
3. 操作フローとデータ処理：
3.1 クライアントは新しい認証認証情報が必要であることを認識します（認証情報がない場合や認証情報が失効している場合など）。
3.2 クライアントは認証サービスと暗号化接続を確立し、認証リクエストを開始して、デバイスとアプリケーションの情報を送信します。
3.3 認証サービスがクライアントを検証し、身分確認を完了します。
3.4 検証が完了すると、認証サービスは新しい認証認証情報を発行し、クライアントに返してローカルに保存し、後続のリクエストで使用します。
4. クライアントの想定される動作
説明：
このフローでは、リクエストはクライアントアプリケーションによって開始され、SDKは通常、事前に設定された認証サービスプロバイダーに検証リクエストを送信します。認証サービスはクライアントデータを検証し、認証情報を返します。これは事前に認証情報を取得するプロセスであるため、まだビジネスバックエンドへのAPI呼び出しは行われず、ビジネスサーバーからの直接応答はありません。
ネットワーク上で、クライアントSDKから認証サービスへの通信を観測できます。具体的な通信先は、設定された認証器のタイプ（デバイス検証や画像Captchaなど）によって異なります。正常に完了すると、クライアントは有効な認証トークンを取得します。
1. フロー概要
クライアントリクエストに有効な認証情報が含まれていない場合、または認証情報の有効期限が切れている場合、サーバーはリクエストを拒否し、HTTP 428ステータスコードで認証チャレンジを開始します。このフローは、サーバー側の要求に従って追加認証を完了するようにクライアントを案内します。
2. 適用シーン
クライアントが保護されたインターフェースに初めてアクセスした場合。例えば、ユーザーがログインした直後でまだ認証されていない状態でビジネスAPIにアクセスすると、サーバーは428を通じてクライアントに初回認証を完了するよう促します。
クライアントの認証情報の有効期限が切れた場合、または取り消された場合。例えば、アプリがバックグラウンドで長時間操作されなかったり、環境の変化によって認証情報が無効になったりした後、ユーザーが再度操作する際に追加認証がトリガーされます。
高いセキュリティ要件のシナリオでは、サーバー側が自発的に再認証を要求します。例えば、ユーザーが取引を実行しようとしたり、重要な設定を変更しようとしたりする場合、サーバー側は最新の認証を要求し、操作リスクを制御可能にします。
3. 操作フローとデータ処理
3.1 クライアントがビジネスサービスにリクエストを送信し、サーバー側が認証情報の無効または欠落を検出すると、HTTP 428を返し、レスポンスヘッダーに認証チャレンジ情報（クライアント認証ID）を付与します。
3.2 クライアントはレスポンスヘッダーのチャレンジ情報を解析し、どの認証を完了する必要があるかを判定します。
3.3 クライアントは再度認証サービスと連携し、チャレンジ内容に基づいて認証情報を補完し、認証操作を完了します。
3.4 認証サービスは検証が完了すると新しい認証情報を発行し、クライアントはそれを保存します。
3.5 クライアントは元のリクエストを再送信し、新しい認証情報をリクエストヘッダーに追加します。
説明：
クライアントが新しい認証情報を正常に取得した後、認証情報をリクエストに正しく追加してからリソースに再度アクセスする必要があります。再度428ステータスコードを受け取った場合は、追加認証フローを再実行する必要があります。
4. クライアントの想定される動作
説明：
一部の認証データは暗号化されているため、外部から内容を直接観測することはできません。そのため、HTTPステータスコードとヘッダーに特定のヘッダーが含まれているかどうかによってのみ、認証フローの状態を判断できます。
初回リクエスト時に、サーバーはHTTP 428を返し、認証チャレンジ
EO-Attest-Challengeヘッダーを含みます。クライアントは追加認証を完了した後、再度リクエストする際に、リクエストの
EO-Attest-Tokenヘッダーに新しい認証情報を含めます。1. フロー概要
クライアントの認証認証情報には有効期間があります。認証情報が失効していない間、クライアントはキャッシュされた認証情報を繰り返し使用できるため、毎回再認証する必要がなく、パフォーマンスが向上し、余分なやり取りが減少します。
2. 適用シーン
アプリケーションがホットスタートまたはフォアグラウンドに戻った場合、既存のセッションを継続します。
複数回のリクエスト中、認証情報は引き続き有効期間内です。
ネットワーク切断から復旧した際、既存の認証情報を再利用しようとします。
3. 操作フローとデータ処理：
3.1 クライアントはローカルで認証認証情報のキャッシュを照会し、有効期限が切れていない有効な認証情報が存在するかどうかを判断します。
3.2 有効な認証情報がある場合、後続のAPIリクエストではこの認証情報を再利用できるため、再認証は不要です。
3.3 認証情報が失効しているか存在しない場合、クライアント認証の開始（認証情報の生成）ステップに戻り、認証を再度開始する必要があります。
4. クライアントの想定される動作
説明：
このフローでは、実際にAPIリクエストが開始された場合のみ、サーバーはリクエストヘッダー内の認証情報を検査してその有効性を判断します。外部からは、リクエストヘッダーに有効な認証情報（例：EO-Attest-Token）が含まれているかどうか、およびサーバーのレスポンスステータスによってのみ、認証情報の実際の使用状況を判断できます。
ローカルで認証情報を照会する際、サーバーとの通信は不要で、すべての操作はローカルで完了します。クライアントはローカルの認証情報を再利用して、通常どおりビジネスリクエストを開始でき、サーバーは直接ビジネスレスポンスを返すため、追加の認証手順は不要です。認証情報が失効した場合、サーバーは428ステータスコードを返し、自動的に追加認証フローに入ります。
1. フロー概要
認証情報の主な目的は、リクエストヘッダーを通じてビジネスサービスに対し、クライアントが認証を完了していることを証明することです。サーバーは、有効な認証情報を含むリクエストに対してのみビジネス処理を行います。
2. 適用シーン
クライアントはログイン、登録、支払い、注文などのビジネスインターフェースを呼び出します。例えば、クライアントが呼び出しパラメータを準備し、ログインAPIインターフェースにアクセスしようとする際には、有効なクライアント認証情報をリクエストに埋め込み、サーバーが最初の段階で検証および確認を行い、不要なチャレンジや重複した認証フローを減らす必要があります。
3. 操作フローとデータ処理：
3.1 クライアントはAPIリクエストを開始する準備をする際に、ローカルの認証情報を
EO-Attest-Tokenリクエストヘッダーを使用してHTTPリクエストに追加します。3.2 サーバーはリクエストを受信した後、認証情報の内容を解析して検証します。
3.3 認証情報が有効な場合、サーバーはリクエストを通過させ、ビジネスレスポンスを返します。
3.4 認証情報が欠落または無効な場合、サーバーはHTTP 428ステータスコードを返し、クライアントに認証の補充を要求します。
4. クライアントの想定される動作
説明：
このフローでは、リクエストはクライアントアプリケーションによって開始され、SDKは通常、事前に設定された認証サービスプロバイダーに検証リクエストを送信します。認証サービスはクライアントデータを検証し、認証情報を返します。これは事前に認証情報を取得するプロセスであるため、まだビジネスバックエンドへのAPI呼び出しは行われず、ビジネスサーバーからの直接応答はありません。
クライアントのすべての保護対象インターフェースリクエストには、
EO-Attest-Token認証情報ヘッダーが付与されます。サーバーはこれに基づいてリクエストの正当性を判断します。リクエストヘッダーに有効な認証情報が含まれている場合、サーバーは正常なビジネスデータを返します。認証情報が不適切または欠落している場合、サーバーはHTTP 428を返し、再認証が必要です。
피드백