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

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

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

前后端分离架构下的OAuth2.0授权流程_第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参数了。

你可能感兴趣的:(Spring,Security,java)