移动端集成第三方OAuth 2.0服务的自定义方案安全咨询

你当前的中转服务器授权码流方案，除了已经意识到的恶意应用冒充Scheme的问题，还存在以下几个安全风险：

• 令牌明文传输泄露风险：直接把access_token和refresh_token放在Deep Link的URL参数里传输，这些参数可能会被系统日志、浏览器跳转记录、甚至具备系统权限的第三方应用捕获，导致敏感凭证泄露。哪怕用了验证过的Deep Link/Universal Link，这个明文暴露的问题依然存在。
• 中转服务器的信任依赖风险：你的服务器全程持有用户的授权码和最终令牌，相当于用户的第三方服务权限完全托管在你的服务器上。一旦服务器被入侵、或者内部人员违规操作，会导致大量用户的凭证泄露；同时，第三方服务对你的服务器的信任关系，也可能被滥用批量获取用户权限。
• 重放攻击风险：如果流程中没有加入一次性校验参数（比如nonce），攻击者可以拦截中转服务器返回的Deep Link请求，重复调用该链接将令牌注入恶意应用。哪怕用了state解密，若state没有设置过期时间或一次性使用限制，也可能被攻击者复用。
• 跳转劫持风险：即便使用了验证过的Universal Link，在部分系统版本或特殊场景下，依然可能出现跳转劫持——比如恶意应用通过系统漏洞或钓鱼手段，诱导用户在授权完成后跳转到伪造页面，再触发恶意的Deep Link窃取令牌。
• 应用侧令牌存储风险：令牌传递到应用后，如果应用未采用安全存储方式（比如明文存在SharedPreferences、未加密的本地数据库），哪怕前面的流程无漏洞，后续也会出现凭证泄露的问题。

针对你提到的两种优化思路，补充几点强化建议：

• 对于绑定验证的Deep Link/Universal Link：除了依赖系统的域名验证，还要在跳转URL中加入动态校验参数（比如带过期时间的签名）。中转服务器生成参数时设置短有效期，应用收到请求后先校验签名和过期时间，确认合法后再处理令牌。
• 对于state参数解密令牌：确保state是应用本地生成的高熵随机值，且中转服务器要记录已使用的state，防止重复利用。加密逻辑上，用state作为对称加密密钥，中转服务器加密令牌后再返回，应用用本地留存的state解密，全程避免state在传输过程中泄露。

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