客户端-服务端架构下如何识别官方客户端并过滤非官方请求？

你现有的统一密钥加密校验方案存在明显的短板：只要有任意使用者逆向官方客户端提取到硬编码的密钥，整个校验规则就会全局失效，且除了全量推送客户端更新替换密钥外没有其他补救方式，不建议直接落地。
以下是不同安全等级、不同实现成本的可选方案，所有方案均不会影响第三方客户端的正常接入，仅用于服务端给请求打身份标签：

低实现成本、低安全等级方案 #

• 仅做请求签名校验，无需全量加密请求内容
• 官方客户端在请求头追加X-Official-Sign字段，字段值由「当前时间戳 + 本次请求内容哈希值 + 客户端内置混淆盐值」按固定规则计算得出，盐值不要明文硬编码，做拆分混淆、运行时动态拼接即可
• 服务端收到请求后用相同规则计算签名，匹配成功即可标记为官方客户端
• 后续可以通过客户端热更新定期替换混淆盐值，就算盐值被逆向泄露也能快速修复，不会导致全局规则长期失效

中等实现成本、中等安全等级方案 #

• 官方客户端首次启动时，向服务端申请专属的设备身份凭证，凭证和设备硬件特征绑定，每个客户端的凭证唯一
• 后续所有请求都用该专属凭证做签名，服务端只需要校验签名合法性即可
• 就算单个客户端被逆向提取出凭证，服务端可以直接拉黑该凭证，不会影响其他官方客户端的正常使用，也不会导致全局规则失效

高实现成本、高安全等级方案 #

• 针对原生客户端，直接用系统自带的可信执行环境存储签名密钥：安卓端用系统KeyStore，iOS端用Secure Enclave，密钥生成后就无法被导出到外部，哪怕客户端被破解也拿不到根密钥
• 每次请求的签名运算都在系统安全区内完成，不会暴露计算逻辑，几乎不存在被逆向伪造的可能

注意：所有校验逻辑仅用于身份标记，不要拦截非官方客户端的合法请求，符合你保留第三方自定义客户端接入的需求。后续可以针对官方客户端开放额外功能、更高的接口调用限额等权益，非官方客户端仅保留基础能力即可。

内容的提问来源于stack exchange，提问作者PeeS