前后端分离架构下的OAuth2.0授权流程

前后端分离案例代码：spring-security-oauth2.0-sample

关于OAuth2.0规范介绍请参考 OAuth 2.0 Simplified
关于OAuth2.1草案介绍请参考 OAuth 2.1

1. 用户点击前端开始第三方登录
2. 前端调用后端接口开始第三方登录
3. 后端组装完client_id，redirect_uri, response_type, state等参数构造重定向到第三方授权服务器的连接，返回给前端。链接如：http://wechat.com/oauth2/code?response_type=code&client_id=clientid&state=state&redirect_uri=http://我的应用前端地址
4. 重定向链接回到浏览器，浏览器准备开始重定向
5. 重定向至第三方应用
6. 第三方应用返回是否授权页面给浏览器
7. 用户点击同意授权，浏览器返回同意给授权服务器
8. 授权服务器根据之前的redirect_uri返回code和state等参数
9. 前端将code和state参数提交给当前应用后端
10. 后端拿着前端返回的code、state和后端保存的client_id和client_secret参数去授权服务器换取accessToken以及refreshToken。（client_secret可以通过url(deprecated since OAuth2.1)、header、body方式传输，常用basic方式）
11. 授权服务器校验参数成功，返回accessToken以及refreshToken给后端
12. 后端拿着accessToken去资源服务器换取受限资源
13. 资源服务器校验accessToken，成功后返回受限资源，后端根据受限资源可做处理
14. 后端 也可将资源返回前端展示…

注意：前端先获取code，也就是前端地址就是redirect_url的地址，wechat直接发送code到前端，然后前端再把code返回后端（为什么不直接返回后端？因为后端不会也不应该直接暴露接口给本应用之外的请求）；甚至再implicit模式下前端直接获取access_token都不需要后端参与，这种需要保证应用处于信任的环境中。(OAuth2.1草案中取消了implicit和password的模式)。

其中state参数是用来防止CSRF攻击的，关于这个问题，可参考 What is the purpose of the ‘state’ parameter in OAuth authorization request 。

此外，OAuth2.0可选、OAuth2.1强制要求的PKCE机制 不光可以用来防止CSRF，还可以防止authorization code injection attacks，这个问题可参考 RFC 7636: Proof Key for Code Exchange，所以用了PKCE就可以不用state参数了。