原生App能否存储用户凭证？采用OpenID授权码流(PKCE)的后台登录流程是否合规？

1. 原生App是否允许存储用户凭证？ #

技术上虽能实现存储用户邮箱和密码，但强烈不建议这么做，核心原因包括：

• 安全风险：明文或弱加密存储用户凭证，一旦App被破解、设备被入侵，用户核心账号信息会直接泄露，风险极高。
• 合规问题：GDPR、苹果App Store审核规范、谷歌Play政策均要求开发者最小化存储敏感用户数据，直接存储密码属于违规高风险行为。
• 更优替代：应存储授权服务器返回的刷新令牌（Refresh Token），这类令牌权限可控、可被服务器随时吊销，无需用户提供原始凭证就能获取新的访问令牌，安全性远高于存储密码。

2. 该登录流程是否属于原生应用的常规实现方式？ #

你描述的“存储用户凭证后用后台浏览器自动发起登录”流程不属于常规最佳实践，原生App基于PKCE的OpenID授权码流的标准实现逻辑是：

• 首次登录：调用系统默认浏览器打开授权服务器的官方登录页面，用户在可信页面输入凭证；授权服务器返回授权码后，App通过PKCE验证，用授权码交换获取访问令牌和刷新令牌，仅存储刷新令牌。
• 后续启动：直接使用本地存储的刷新令牌向授权服务器请求新的访问令牌，无需再次触发浏览器登录流程；仅当刷新令牌失效时，才引导用户重新走完整授权登录流程。

采用后台浏览器实例自动登录的问题在于：

• 安全隐患：后台浏览器实例无法利用系统级安全存储机制，易被恶意程序劫持，增加凭证泄露风险。
• 违背协议设计：OAuth2/OpenID Connect的核心设计之一是让用户在授权服务器的可信界面输入凭证，避免App直接接触或存储敏感密码。
• 审核风险：苹果和谷歌的应用审核团队可能因该流程存在安全漏洞，拒绝应用上架。

内容的提问来源于stack exchange，提问作者Ivan-Mark Debono