xiaxiaolu

Working with Proof Key for Code Exchange (PKCE) - DEV Community

写在前面

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

  • Authorization Code+ PKCE
  • Client Credentials
  • Device Code

作为完美踩坑ImplicitPassword 两种flow的人,有点感慨,特来发表下自己的愚见;

并带着以下问题:

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

Implicit 和 Password 的问题

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

Implicit的问题

  • 1、比较容易泄露access_token(下文简称token), 比如有的开发者条件不允许,web 服务用http的协议直接上生产(正确是一定要用https);
  • 2、token直接暴露在请求里,如果token权限不控制好的话用户能轻而易举调用不该有权限的接口;

解决方案:

改为用 :Authorization Code + PKCE

Password的问题

园友已经说的很清楚了我总结下;

  • 1、最大的问题就是违背了委托授权的原则,比如我的Web服务用微信登录用的Password flow的话,那意思是需要在我的登录页面里面填写微信的账号和密码,这眼见的不可思议和不合理吧;

我个人看法:

虽然目前OAuth2最佳实践中已经明确要求不能使用这种模式,但是 原有已经使用是这种模式的自有App还是可以接着使用的 没有问题;因为自有App和自有授权中心没有需要授权,是一起的;

如果是新开发App呢,还是优先考虑:Authorization Code + PKCE,毕竟Password已经是过时的流程了;

思考Authorization Code+ PKCE在Native App使用的问题

先回顾Authorization code Flow

img

图来自

回顾流程和请求

我这里是web服务,用的是SPA的客户端,授权服务用的是IdentityServer4;

假设授权服务是:https://localhost:44356/ 客户端是:https://localhost:44357/

  • A、先判断登录、未登录先引导用户去授权服务器授权(一般是打开授权方登录页面);

判断登录

https://localhost:44356/connect/authorize?client_id=vuejs_code_client&redirect_uri=https%3A%2F%2Flocalhost%3A44357%2Fcallback.html&response_type=code&scope=openid profile dataEventRecords&state=10f308dbb5d54c01be3b97c495569e8c&code_challenge=gp1EWoH_KsIdL6sGyohEIR6815PcVmz05V_dYvPbafI&code_challenge_method=S256&response_mode=query

登录页面

https://localhost:44356/Account/Login?ReturnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3Dvuejs_code_client%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A44357%252Fcallback.html%26response_type%3Dcode%26scope%3Dopenid%2520profile%2520dataEventRecords%26state%3D10f308dbb5d54c01be3b97c495569e8c%26code_challenge%3Dgp1EWoH_KsIdL6sGyohEIR6815PcVmz05V_dYvPbafI%26code_challenge_method%3DS256%26response_mode%3Dquery

  • C、登录成功返回Authorization code;

登录成功回调

https://localhost:44356/connect/authorize/callback?client_id=vuejs_code_client&redirect_uri=https%3A%2F%2Flocalhost%3A44357%2Fcallback.html&response_type=code&scope=openid profile dataEventRecords&state=10f308dbb5d54c01be3b97c495569e8c&code_challenge=gp1EWoH_KsIdL6sGyohEIR6815PcVmz05V_dYvPbafI&code_challenge_method=S256&response_mode=query

https://localhost:44357/callback.html?code=C0EF4B31E9F67481019DC51ED3F393264973027E0275644915314ED25F0F95B7&scope=openid profile dataEventRecords&state=10f308dbb5d54c01be3b97c495569e8c&session_state=j4dyIjlHucHYEHMrli0nBisCinR9Iq9gncp3khniF58.6A5CBF9592729E89570BE9FAC8A962DF

  • D、通过code去授权中心token endpoint换取token;

post 请求
https://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服务器通过http://localhost:port/?code=的方法监听code

这两种方式都有被第三方恶意应用占用URL Scheme或者localhost端口截取code的风险

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

所以引出我们的PKCE流程;

Authorization Code**+ **PKCE在Native App中使用

img

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_challengecode_challenge_method来发起授权请求,生成关联这两项值的code;
  • 4、用code和code_verifier去换取token;
  • 5、授权服务器返回token,和refresh token(app这个很重要);

我们可以看到,因为我们的code已经关联code_challengecode_challenge_method,即时攻击者拦截了也没用了,因为你没有code_verifier,你同样换不到token;;

最后,可以看到整个PKCE流程设计精妙,已经解决了Code传参问题;

总结

有了PKCE, 在Native App中使用Code传参的话直接用原先的方式:

  • 1、是绑定URL Scheme通过类似app-name://?code=的方法把code传递给原生客户端;
  • 2、在本地起个HTTP服务器通过http://localhost:port/?code=的方法监听code

传递code就行;

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

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

水完,over.

参考

https://www.cnblogs.com/felordcn/p/16011138.html

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

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

相关文章: