OAuth2.0 Authorization Code PKCE流程在原生应用中如何高效集成？

2026-05-22 14:161阅读0评论SEO基础

内容介绍
文章标签
相关推荐

本文共计976个文字，预计阅读时间需要4分钟。

OAuth2.0 Authorization Code PKCE流程在原生应用中如何高效集成？

近期阅读了关于园友的一篇文章，讨论了OAuth2.0中广泛应用的密码模式已废弃。再次提起：隐式流（Implicit Flow）密码授权，已被标记为Legacy，OAuth2.1中已删除。目标：OAuth

写在前面

前几天看了园友的一篇文章被广泛使用的OAuth2.0的密码模式已经废了，放弃吧被再次提起： Implicit Flow Password Grant，均已被标记为Legacy，且OAuth2.1里面已经删除了，目前OAuth2.1只剩三种flow：

Authorization Code+ PKCE
Client Credentials
Device Code

作为完美踩坑Implicit 和 Password 两种flow的人，有点感慨，特来发表下自己的愚见；

并带着以下问题：

在SPA(单页面应用程序Vue等)中不再用Implicit flow，还能用什么？
在Native App和小程序等Public Client中不再用Password flow，还能用什么？

Implicit 和 Password 的问题

以下均为个人理解，不保证全对

Implicit的问题

1、比较容易泄露access_token(下文简称token), 比如有的开发者条件不允许，web 服务用localhost:44356/ 客户端是：localhost:44357/
- A、先判断登录、未登录先引导用户去授权服务器授权（一般是打开授权方登录页面）；
判断登录

localhost:44356/connect/authorize?client_id=vuejs_code_client&redirect_uri=localhost:44356/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dvuejs_code_client%26redirect_uri%3Dlocalhost:44356/connect/authorize/callback?client_id=vuejs_code_client&redirect_uri=localhost:44357/callback.html?code=C0EF4B31E9F67481019DC51ED3F393264973027E0275644915314ED25F0F95B7&scope=openid profile dataEventRecords&state=10f308dbb5d54c01be3b97c495569e8c&session_state=j4dyIjlHucHYEHMrli0nBisCinR9Iq9gncp3khniF58.6A5CBF9592729E89570BE9FAC8A962DF
- D、通过code去授权中心token endpoint换取token;
post 请求
localhost:44356/connect/token

ok，以上流程后拿到token后面的请求Resource Owner就没问题了。
Authorization code Flow在Native App中使用有何问题
首先是Authorization code流程里面的，code参数传递通过重定向的方式，在原生App里一般这样重定向一般有两种方式：
- 1、是绑定URL Scheme通过类似app-name://?code=的方法把code传递给原生客户端；
- 2、在本地起个HTTP服务器通过localhost:port/?code=的方法监听code
这两种方式都有被第三方恶意应用占用URL Scheme或者localhost端口截取code的风险。

另一个问题是，Authorization code code换取token的时候需要app_secret这些；

所以引出我们的PKCE流程；
Authorization Code + PKCE在Native App中使用

PKCE在这篇文章里面已经讲得很清楚了，我简单总结下：

上文我们已经清楚，Authorization code(简称code)流程里面的，code传递给原生App的两种方式都不安全，那么引出PKCE的概念：

PKCE

全称Proof Key for Code Exchange，直译：用一个Proof key来做Code交换；

解决的问题是，既然你可以拦截我的Authorization code，那我再加一个我有，你没有的参数(等于是票据、验证凭据)做code交换条件就行；

PKCE步骤为：
- 1、先随机生成一串字符串叫code_verifier；
- 2、用code_challenge_method方法(sha256等)把code_verifier加密成code_challenge；
- 3、把code_challenge和code_challenge_method来发起授权请求，生成关联这两项值的code;
- 4、用code和code_verifier去换取token;
- 5、授权服务器返回token，和refresh token(app这个很重要);
我们可以看到，因为我们的code已经关联code_challenge和code_challenge_method，即时攻击者拦截了也没用了，因为你没有code_verifier，你同样换不到token;；

最后，可以看到整个PKCE流程设计精妙，已经解决了Code传参问题；
总结
有了PKCE, 在Native App中使用Code传参的话直接用原先的方式：
- 1、是绑定URL Scheme通过类似app-name://?code=的方法把code传递给原生客户端；
- 2、在本地起个HTTP服务器通过localhost:port/?code=的方法监听code
传递code就行；

另外还有一种方式，直接在Native App里面嵌入Webview来传递，在携带code重定向这个步骤，拦截重定向url，获取code，换取token;

现在我看到很多App都是这样做的;

水完，over.
参考
www.cnblogs.com/felordcn/p/16011138.html

www.cnblogs.com/myshowtime/p/15555538.html

medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926

标签：关于 OAuth20 Authorization Code