02 | 授权码许可类型中，为什么一定要有授权码？笔记

02 | 授权码许可类型中，为什么一定要有授权码？

小兔最终是通过访问令牌请求到小明的店铺里的订单数据。这个访问令牌是通过授权码换来的。为什么要用授权码来换令牌？为什么不能直接颁发访问令牌呢?

为什么需要授权码？

在 OAuth 2.0 的体系里面有 4 种角色，按照官方的称呼它们分别是资源拥有者、客户端、授权服务和受保护资源.客户端用第三方软件称呼。
资源拥有者 -> 小明，第三方软件 -> 小兔软件，授权服务 -> 京东商家开放平台的授权服务，受保护资源 -> 小明店铺在京东上面的订单。
OAuth 诞生之初就是为了解决 Web 浏览器场景下的授权问题，

如果没有授权码，直接把访问令牌发送给第三方软件小兔的后端服务，这样会把安全保密性要求极高的访问令牌暴露在浏览器上

这里有个问题，当小明被浏览器重定向到授权服务上之后，小明跟小兔软件之间的 “连接” 就断了，相当于此时此刻小明跟授权服务建立了“连接”后，将一直“停留在授权服务的页面上”。你会看到图 2 中问号处的时序上，小明再也没有重新“连接”到小兔软件。
小兔软件已经拿到了小明授权之后的访问令牌，可以获取到订单数据，小兔软件应该通知小明，但是现在连接断了，通知不了。所以还必须让小明跟小兔软件重新建立起 “连接”。这就是我们看到的第二次重定向。

授权码许可类型的通信过程

间接通信

直接通信

两个 “一伙”

资源拥有者和第三方软件“站在一起”，因为第三方软件要代表资源拥有者去访问受保护资源；授权服务和受保护资源“站在一起”，因为授权服务负责颁发访问令牌，受保护资源负责接收并验证访问令牌。

一定要有浏览器吗？

OAuth 2.0 是一个授权理念，或者说是一种授权思维。它的授权码模式的思维可以移植到很多场景中，比如微信小程序。

总结

1. 授权码许可流程有两种通信方式。
2. 在 OAuth 2.0 中，访问令牌被要求有极高的安全保密性，因此我们不能让它暴露在浏览器上面，只能通过第三方软件（比如小兔）的后端服务来获取和使用，通过授权码的方式，可以让用户小明在授权服务上给小兔授权之后，还能重新回到小兔的操作页面上。
   原文