原生移动应用无浏览器认证：替代Authorization Code Flow with PKCE的合规方案

针对你提到的用户反感浏览器跳转、需要原生体验的场景，以下是从安全角度出发、具备成熟实现支持的认证方案：

1. OAuth 2.0 资源所有者密码凭证（ROPC）流程 #

• 适用场景：仅支持自有账号密码/手机号认证的原生应用，全程在APP内完成输入，完全无需跳转浏览器。
• 安全要点：
  • 所有请求必须走HTTPS，杜绝明文传输风险。
  • 仅限用于你完全信任的自有应用——因为APP会直接处理用户密码，一旦APP被逆向破解存在密码泄露风险。
  • 搭配短有效期的access token + 刷新token使用，即使access token泄露，影响范围也有限。
• 实现支持：
  • 主流后端框架（Spring Security、Node.js Passport、Django OAuth Toolkit等）都有成熟的ROPC实现。
  • 移动端无需复杂SDK，直接用常规HTTP客户端（比如Retrofit、AFNetworking）发起请求即可。

2. OpenID Connect (OIDC) 直接认证扩展 #

• 适用场景：需要ID token做身份断言、同时追求原生体验的场景，基于OIDC的直接认证扩展，跳过浏览器跳转环节。
• 安全要点：
  • 遵循OIDC规范，支持token签名验证，能确保身份凭证的合法性和不可篡改性。
  • 同样要求HTTPS传输，支持刷新token机制，可定期轮换凭证。
  • 部分身份提供商（如Keycloak）支持设备绑定，进一步提升安全性。
• 实现支持：
  • 后端可对接Keycloak、Auth0等身份提供商的直接认证API。
  • 移动端可使用官方SDK快速集成，比如Keycloak有专门针对iOS和Android的SDK支持直接认证流程。

3. 自定义JWT认证流程（需严格遵循安全规范） #

• 适用场景：需要高度定制化认证逻辑的场景，完全自主实现，但必须严格遵守JWT安全标准。
• 安全要点：
  • 使用签名JWT（优先选RSA256非对称加密，避免HS256对称密钥泄露风险），防止token被篡改。
  • access token设为短有效期（比如15分钟），刷新token存储在移动端安全容器（iOS的Keychain、Android的Keystore）中，禁止明文存储。
  • 手机号验证码场景：验证码通过短信/推送下发，APP完成验证后直接向后端请求token。
• 实现支持：
  • 移动端可使用成熟的JWT库（iOS的JWTDecode、Android的jjwt）处理token解析与验证。
  • 后端集成成本低，多数开发框架都有现成的JWT生成与验证工具。

必须遵守的通用安全准则 #

• 绝对不能在APP代码中硬编码敏感密钥，所有密钥相关逻辑放在后端处理。
• 强制关闭HTTP请求，所有接口仅允许HTTPS访问，防止中间人攻击。
• 刷新token要严格存储在系统级安全容器，不要存在SharedPreferences、UserDefaults这类易被读取的存储中。
• 定期更新token签名算法，避免使用MD5、SHA1这类弱加密算法。

内容的提问来源于stack exchange，提问作者M.R.M