Android/iOS WebView混合应用的OAuth流程选择及令牌存储问询

1. Android/iOS WebView属于Public Client吗？ #

是的，WebView中的JavaScript代码环境完全属于Public Client范畴。虽然你的混合应用有原生层可以访问keystore这类安全存储，但WebView里的JS代码无法安全持有客户端密钥——任何存在于JS环境的密钥，都可能被XSS攻击、调试工具或恶意脚本轻易窃取。从OAuth的定义来看，Public Client就是无法安全保管客户端凭证的客户端，WebView显然完全符合这个特征。

2. WebView是否易受XSS攻击？ #

绝对是，甚至风险比普通桌面浏览器更高：

• WebView通常会开放与原生层交互的桥接接口（比如你提到的访问keystore的能力），一旦JS被XSS攻陷，攻击者可以通过这些接口直接调用原生功能，窃取敏感数据或执行恶意操作。
• 很多混合应用为了兼容性，可能会放宽WebView的安全配置（比如允许file://协议、禁用内容安全策略CSP等），这进一步放大了XSS风险。

必须做好防护：开启严格的内容安全策略（CSP）、严格过滤所有用户输入、禁用eval()等危险API、限制WebView与原生交互的权限范围，只开放必要的接口。

3. 混合应用应该采用哪种OAuth流程？ #

推荐使用授权码流程+PKCE扩展，彻底替代旧的Implicit流程，原因如下：

• Implicit流程直接在前端返回令牌，令牌暴露在URL或JS环境中，泄露风险极高，早已不是行业最佳实践。
• 授权码流程+PKCE不需要客户端密钥，完美适配Public Client；PKCE的code_verifier机制能有效防止授权码被拦截，即使WebView存在漏洞，也能大幅提升流程安全性。

更优的进阶实践：让原生层主导OAuth流程：

• 由原生代码生成code_challenge和code_verifier，把code_verifier安全存储在原生的keystore/Keychain中。
• 用原生系统的浏览器组件（比如Android的Custom Tabs、iOS的SFSafariViewController）发起授权请求，而非WebView内部——这样能避免WebView的XSS风险影响授权流程，同时利用系统浏览器的安全特性。
• 授权完成后，由原生层获取授权码，再调用令牌端点交换访问令牌和刷新令牌，全程不让令牌经过WebView的JS环境。

如果必须在WebView内处理授权，一定要强制使用PKCE，并且尽量缩短令牌的有效期，配合刷新令牌使用（刷新令牌也要存在原生安全存储中）。

4. 令牌应该存储在哪里？ #

绝对不要存在WebView的localStorage、sessionStorage或普通Cookie中——XSS攻击可以直接读取这些存储位置的内容，风险极高。

正确的存储方式是：

• Android：使用Keystore存储令牌，它能加密存储敏感数据，且只有你的应用能访问，提供硬件级别的安全保障。
• iOS：使用Keychain Services，同样提供硬件加密存储，权限控制严格，只有你的应用可以读取。

如果JS层需要调用后端API，可以通过原生提供的桥接接口来代理请求：JS发起请求到原生层，原生层带上令牌调用后端API，再把结果返回给JS——这样令牌全程不会暴露在JS环境中，从根源上降低泄露风险。

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