仅提供Authorization Code Grant的API下，Web与移动应用认证方案可行性咨询

先给你吃个定心丸：方案2是完全可行的，而且对于你的场景来说，可能是比方案3更轻量、更直接的选择。

为什么方案2可行？ #

Authorization Code Grant要求客户端密钥的核心原因是防止授权码被恶意拦截后滥用——毕竟密钥只有可信的客户端持有。但Web前端和移动应用属于"公共客户端"，没法安全存储密钥，所以用自己的Web服务器做代理，刚好解决了这个矛盾：

• 你的代理服务器作为"可信客户端"，安全存储好API的客户端密钥
• 当你的Web/移动应用需要认证时，先把请求转发到代理服务器，由代理和API的授权服务器完成完整的Authorization Code Grant流程（这里还可以加上PKCE来进一步提升安全性，PKCE本来就是为公共客户端设计的，代理层可以完美适配）
• 代理拿到access token后，再返回给你的应用；后续你的应用调用API时，要么直接用token请求，要么继续通过代理转发（看API的具体要求）

方案2的优势 #

• 不需要引入第三方认证服务（比如Auth0），减少额外的依赖和学习成本，也不用让用户额外关联账户
• 你完全控制认证流程的细节，可以精准适配现有API的授权规则
• 客户端密钥只在你的服务器上存储，符合Authorization Code Grant的安全规范

方案3什么时候更适合？ #

方案3（自建/用第三方认证系统）并非唯一选项，但如果你的应用有这些需求，它会更合适：

• 需要支持多租户、社交登录、复杂的权限管控等超出原有API的认证功能
• 不想维护自己的代理服务器，希望把认证逻辑完全外包
• 未来可能对接多个不同的API，需要统一的认证入口

实现方案2的注意点 #

• 一定要正确实现PKCE：生成随机的code_verifier和对应的code_challenge，确保授权服务器返回授权码时能正确验证，防止授权码被劫持
• 代理服务器要做好安全防护：强制HTTPS通信，添加速率限制、CSRF防护，避免被恶意攻击
• 移动端应用和代理通信时，也要确保传输安全，避免token在网络中泄露

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