Authorization Code Grant：原生App对接WebAPI的令牌使用与授权疑问

核心结论 #

绝对不能在客户端完成authorization code到access token的兑换，必须由后端处理兑换流程，并生成自有后端认证令牌供客户端使用。

分点解答你的问题 #

1. 能否在客户端兑换access token？ #

不行。你的身份提供商不允许创建公开客户端，说明兑换token必须使用客户端密钥，但原生应用（iOS/Android等）无法安全存储密钥——密钥会被反编译提取，直接导致密钥泄露，进而引发身份提供商API被滥用、用户账号被盗等风险。

2. 正确的兑换流程是什么？ #

客户端获取到authorization code后，立即将code发送到你的后端服务，由后端使用存储在服务器端的客户端密钥，向身份提供商发起兑换请求，获取access token、refresh token以及用户身份信息。

3. 身份提供商的access token能否直接用作后端的认证令牌？ #

不建议直接使用。原因如下：

• 该token的设计目的是让你的后端访问身份提供商的资源（比如获取用户头像、邮箱），而非用来认证用户访问你的自有API；
• 令牌的有效期、权限范围由身份提供商定义，你无法自主控制，可能适配不了你的后端业务需求；
• 若该token泄露，攻击者可直接访问用户在身份提供商的关联资源，风险波及面更大。

4. 后端应该如何处理认证？ #

后端完成token兑换并验证用户身份有效性后，需要生成自有后端认证令牌（比如JWT），返回给客户端。客户端后续访问你的WebAPI时，携带这个自有令牌进行身份验证。

方案影响对比 #

• 客户端兑换方案：密钥泄露风险极高，违反身份提供商的规则，可能导致你的应用被封禁，用户账号安全无法保障；
• 后端兑换+自有令牌方案：密钥安全存储在后端，你可完全控制令牌的有效期、权限范围，即使自有令牌泄露，攻击者仅能访问你的后端资源，不会影响用户在身份提供商的账号，安全性和可控性更强。

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