客户端、SDK、EdgeOne 边缘和认证服务是客户端认证流程中的主要参与者，通过认证流程协作，确保请求来源的合法性、有效性，防止未经授权的访问和恶意攻击。掌握并正确使用客户端认证流程，可以有效降低安全风险，提高服务的整体可靠性。本文详细讲解客户端认证的具体操作步骤，帮助开发者和用户快速理解并有效使用客户端认证功能，以确保应用的安全性与稳定性。
不同客户端的认证流程适配
根据客户端类型，客户端认证提供了对应的认证流程，以便最大限度提供灵活便捷的集成选项。
认证流程 | 移动端（Android & iOS） | WebView / 浏览器 |
SDK 集成方式 | 客户端开发集成 | 自动集成（JS 注入） 手动集成（前端页面适配集成） |
发起客户端认证（生成认证凭证） | 需要集成 | 无需集成（SDK 自动处理） |
处理挑战（按需补充认证） | | |
获取已有认证凭证（查询已有认证） | | |
在请求中嵌入认证凭证（应用认证凭证） | | |
认证流程
客户端认证流程包括以下几个关键阶段，下面逐一介绍每个阶段的具体操作方法、适用场景以及网络请求层面的表现：
1. 流程概述
主动发起客户端认证可以为客户端生成一份新的认证令牌（Attestation Token），确保后续的 API 请求附带有效凭证。通过主动触发客户端认证，SDK 会对当前设备和应用进行完整校验，并返回一个加密的认证令牌，用以证明客户端满足安全要求。该令牌包含认证平台、认证方式、时间戳等信息，且无法人工篡改。
2. 适用场景
客户端应用初始化时，手动进行新的认证。例如：用户第一次安装并启动 App 时，客户端会主动发起认证，建立可信身份。
认证凭证过期后，客户端重新进行认证。当用户长时间未操作或切换账号，原有认证凭证已过期，客户端会自动重新认证，确保安全性。
处理服务端挑战时，客户端根据挑战要求进行认证。某些关键操作或敏感接口访问时，服务端可能要求客户端强制重新认证，防止凭证被滥用。
3. 操作流程与数据处理：
3.1 客户端识别出需要新的认证凭证（如无凭证或凭证已失效）。
3.2 客户端与认证服务建立加密连接，发起认证请求，提交设备和应用信息。
3.3 认证服务验证客户端，完成身份校验。
3.4 验证通过后，认证服务签发新的认证凭证，返回客户端本地保存，供后续请求使用。
4. 客户端行为预期
说明：
在此流程中，请求由客户端应用发起，SDK 通常会向预先配置的认证服务提供方发送校验请求，认证服务验证客户端数据并返回凭证。由于这是预先获取凭证的过程，还未对业务后端发起 API 调用，因此业务服务器无直接响应。
在网络上可观测到客户端 SDK 向认证服务的通信。具体通信对象取决于配置的认证器类型（如设备校验、图形验证码等）。成功完成后客户端获得有效认证令牌。
1. 流程概述
当客户端请求未携带有效凭证或凭证已过期时，服务器会拒绝请求并以 HTTP 428 状态码发起认证挑战。此流程将指引客户端，根据服务端要求完成补充认证。
2. 适用场景
客户端首次访问受保护接口时。例如：用户刚刚登录、尚未认证时访问业务 API，服务端会通过 428 提示客户端完成首次认证。
客户端凭证过期或被撤销时。例如： App 在后台长时间未操作，或凭证因环境变化失效，用户重新操作时会触发补充认证。
高安全要求场景下，服务端主动要求再次认证。例如：用户尝试进行交易、修改关键设置，服务端要求进行最新认证，确保操作风险可控。
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，需重新认证。
