OAuth2.0协议 第三方登录 授权

1. 引言简单了解

如果你开车去酒店赴宴，你经常会苦于找不到停车位而耽误很多时间。是否有好办法可以避免这个问题呢？有的，听说有一些豪车的车主就不担心这个问题。豪车一般配备两种钥匙：主钥匙和泊车钥匙。当你到酒店后，只需要将泊车钥匙交给服务生，停车的事情就由服务生去处理。与主钥匙相比，这种泊车钥匙的使用功能是受限制的：它只能启动发动机并让车行驶一段有限的距离，可以锁车，但无法打开后备箱，无法使用车内其他设备。这里就体现了一种简单的“开放授权”思想：通过一把泊车钥匙，车主便能将汽车的部分使用功能（如启动发动机、行驶一段有限的距离）授权给服务生。

2. OAuth 2.0 协议

之所以标注为 2.0，是因为最初有一个1.0协议，但这个1.0协议被弄得太复杂，易用性差，所以没有得到普及。2.0是一个新的设计，协议简单清晰，但它并不兼容1.0，可以说与1.0没什么关系。所以，我就只介绍2.0。

在弄清楚OAUTH流程之前，我们先了解下OAUTH的一些术语的定义：

• OAUTH相关的三个URL：
  • Request Token URL: 获取未授权的Request Token服务地址；
  • User Authorization URL: 获取用户授权的Request Token服务地址；
  • Access Token URL: 用授权的Request Token换取Access Token的服务地址；

OAuth授权分四步。

　　第一步，应用向服务提供方申请请求令牌(Request Token)，服务提供方验证通过后将令牌返回。这个步骤由于涉及到应用帐号密码，在应用的服务端发起，所以这个步骤对用户透明。

　　第二步，应用使用请求令牌让浏览器重定向到服务提供方进行登录验证和授权。服务提供方校验请求令牌，将第三方的资料显示给用户，提示用户选择同意或拒绝此次授权。如果用户同意授权，发放已授权令牌并将用户引导到当前应用的注册地址。这个步骤从重定向开始到引导回注册地址之前，应用方并不参与用户身份校验和授权过程，确保第三方不可获得用户的真实帐号密码。

　　第三步，用已授权令牌向服务提供方换取ATOK。第三方应用需在服务端发起请求，用帐号密码和上一步的令牌换取ATOK，这个步骤对用户而言也是透明的。如果前两步分别是让服务提供方认证应用和用户，那这步就是用户和服务提供方再次认证第三方应用。因为用户浏览器将第二步的结果重定向到第三步，除非用户DNS被劫持，否则就能确保重定向到的是合法的地址。曾经我很困惑在用户授权之后为何不直接返回ATOK而需要再次换取，估计是出于对ATOK的安全考虑，用户浏览器一端存在太多的可能性让ATOK泄漏，最安全的办法还是让第三方服务端来获取和保管ATOK。

　　第四步，用ATOK作为令牌访问受保护资源。很多时候，权限是有多种类别的。ATOK包含了某个用户对某个应用的授权凭据，准确的说，ATOK对应用户授权时所赋予的一系列权限的集合。所以在这一步，除了校验ATOK的合法性之外，服务提供方还需对该ATOK是否拥有足够的权限执行被保护操作进行判断。