OAuth2.0 PKCE

0x00 背景

最近好好学习了一下OAUTH2.0,发现OAUTH2.0有很多认证方式,code flow和impicit flow大家都已经很熟悉了,我来总结一下使用pkce的code flow。
顺便,这个链接可以用来参考你该使用哪种flow:
https://auth0.com/docs/api-auth/which-oauth-flow-to-use

0x01 code flow with PKCE

PKCE模式适用于功能逻辑主要在客户端完成的native app。因为native app没有浏览器那样的cookie支持,Resource Server没有session这样的东西来保存state参数从而防止CSRF,所以使用PKCE的code_verifier和code_challenge来防止CSRF。这里主要考虑到的威胁是,native app必须经过浏览器才能进行redirect操作,在下图的第③步中,由于使用了app的custom schemer,如果有恶意app注册了同一个schemer,则不能保证第③步的重定向会回到你的app。
PKCE

0x02 其他flow的弱点

如果Resource Server的实现有问题会有下面这些问题:

  1. implicit flow
    a. 可能受到token replace攻击
    b. 可能受到csrf攻击
    c. 可能受到covert redirect攻击(虽然Auth Sever会检测callback的URL是否符合CP事先注册的域名,但是如果CP提供了open redirector,则在返回Resource Server后,Resource Server再次redirect的话就会产生这个问题)
  2. code flow
    a. 可能受到csrf攻击
    b. 可能受到covert redirect攻击(code与state并不是一一对应的,所以即使你做了csrf防御,code泄露后也是可以被攻击者使用,攻击者使用他的state和泄露的受害者的code即可获得受害者的权限)
  3. code flow with pkce
    无懈可击

另外,implicit flow和pkce都不需要client secret,所以不存在client secret泄露问题。

0x03 参考

https://security.stackexchange.com/questions/175465/what-is-pkce-actually-protecting
https://www.atmarkit.co.jp/ait/articles/1710/24/news011.html

前提是所有随机数生成算法没问题