Oauth2.0 安全性问题，code，CSRF与PKCE

性问题，code，CSRF与PKCE"/>

Oauth2.0 安全性问题，code，CSRF与PKCE

为什么需要code

这是一个安全性问题，发起认证请求的是浏览器端或者app，第三方认证重定向也只能重定向到浏览器web端，如果这时直接返回token而非code，那么攻击者通过返回的token就可以使用token来获取用户相关信息（比如Facebook昵称等），而Facebook无法感知是谁发起的请求，所以是不安全的。而返回一次性的code，攻击者就无法发起攻击，并且Facebook可以校验客户端的信息，所以更安全。

CSRF攻击

上图是OAuth2.0授权码授权流程，可以看到，流程中用户整体发起了两次请求到认证服务器后端，且这两次请求是分离的，因此给攻击者发起CSRF攻击制造了条件。即攻击者通过前三步生成攻击者的含授权码的RedirectURL，引导在webapp上已登陆的用户点击恶意网站上的恶意链接（攻击者的含授权码的RedirectURL），这样就会继续步骤6后续流程，造成webapp登陆的用户账号绑定攻击者的第三方账号。

可以看到，CSRF攻击应用在授权码认证流程的条件是用户必须已经登录了第三方网站。即通过将攻击者微博账号与第三方应用账号绑定，获得用户第三方账号相关内容，以实现攻击。

OAuth2.0也提供了相应的解决方案，就是步骤2增加state随机字段，并在步骤5校验，即可验证用户有效性。

具体流程如下：

1、用户甲到第三方网站A登录后，到了绑定页面。此时还没绑定微博。绑定页面提供一个按钮：“绑定微博”（地址a： .php?m=user_3rd_bind_sina ）

2、用户点击地址a，程序生成如下地址b（为方便大家查看，参数部分均未urlencode以【】包含显示）： =【9999999】&redirect_uri=【=user_3rd_bind_sina_callback】&response_type=【code】&state = xyz123456

3、用户甲浏览器定向到地址b，授权该应用。

4、授权服务器根据传递的redirect_uri参数，组合认证参数code生成地址c： =user_3rd_bind_sina_callback&code=【809ui0asduve】&state = xyz123456

5.第三方网站服务器本地校验state参数是否符合，并进行后续流程。这样，第三方网站服务器就有了验证两次发送到微博授权平台是否属于同一流程的能力。

PKCE增强

PKCE，全称 Proof Key for Code Exchange。这其实是通过一种密码学手段确保恶意第三方即使截获Authorization Code 或者其他密钥，也无法向认证服务器交换Access Token。

那么上述流程为何回呗第三方截获呢？这与客户端的安全性有关，与有服务端的客户端不同，原生客户端（即没有服务端的纯桌面应用程序、安卓、IOS、浏览器插件程序等）在授权码模式下，客户端clientID clientSecret的安全性是无法得到保证的，因此有可能被攻击者利用。

基于上述原因，OAuth提供了PKCE增强的授权码模式，主要区别在于，请求/authorize接口之前生成了code_verifier，code_challenge，并携带code_challenge。在请求/token是携带code_verifier在服务提供方来校验身份。