小兔最终是通过访问令牌请求到小明的店铺里的订单数据。这个访问令牌是通过授权码换来的。为什么要用授权码来换令牌?为什么不能直接颁发访问令牌呢?
在 OAuth 2.0 的体系里面有 4 种角色,按照官方的称呼它们分别是资源拥有者、客户端、授权服务和受保护资源.客户端用第三方软件称呼。
资源拥有者 -> 小明,第三方软件 -> 小兔软件,授权服务 -> 京东商家开放平台的授权服务,受保护资源 -> 小明店铺在京东上面的订单。
OAuth 诞生之初就是为了解决 Web 浏览器场景下的授权问题,
如果没有授权码,直接把访问令牌发送给第三方软件小兔的后端服务,这样会把安全保密性要求极高的访问令牌暴露在浏览器上
这里有个问题,当小明被浏览器重定向到授权服务上之后,小明跟小兔软件之间的 “连接” 就断了,相当于此时此刻小明跟授权服务建立了“连接”后,将一直“停留在授权服务的页面上”。你会看到图 2 中问号处的时序上,小明再也没有重新“连接”到小兔软件。
小兔软件已经拿到了小明授权之后的访问令牌,可以获取到订单数据,小兔软件应该通知小明,但是现在连接断了,通知不了。所以还必须让小明跟小兔软件重新建立起 “连接”。这就是我们看到的第二次重定向。
间接通信
直接通信
资源拥有者和第三方软件“站在一起”,因为第三方软件要代表资源拥有者去访问受保护资源;授权服务和受保护资源“站在一起”,因为授权服务负责颁发访问令牌,受保护资源负责接收并验证访问令牌。
OAuth 2.0 是一个授权理念,或者说是一种授权思维。它的授权码模式的思维可以移植到很多场景中,比如微信小程序。
上一篇:Java知识复习(十四)JS