oauth2.0 授权机制及实现

初识oauth

OAuth是一个关于授权（authorization）的开放网络标准，在全世界得到广泛应用，简单的阐述就是你想通过你的github账号信息登录到博客园，博客园应该如何从你手里获得授权凭证，然后该授权凭证从github上获取你的信息，而不会被github拒之门外。

这样的场景其实已经司空见惯，只是没有细心思考他的实现原理。例如我们通常使用微信、QQ、微博账号等登录到其他大大小小的网站，而这些网站就可以获取到一些公开的例如用户名等基本信息，从而实现了用户身份的认证。这样的场景背后。使用的理论基础就是oauth协议，目前他的版本为2.0，所以常叫做oauth2.0。

要实现的上面的场景，就需要设计一种方式来完成github，博客园，和我们用户之间的身份认证，在网上看到这样一个例子，个人感觉十分形象

我住在一个大型的居民小区，小区有门禁系统，进入的时候需要输入密码，我经常网购和外卖，每天都有快递员来送货。我必须找到一个办法，让快递员通过门禁系统，进入小区。如果我把自己的密码，告诉快递员，他就拥有了与我同样的权限，这样好像不太合适。万一我想取消他进入小区的权力，也很麻烦，我自己的密码也得跟着改了，还得通知其他的快递员。有没有一种办法，让快递员能够自由进入小区，又不必知道小区居民的密码，而且他的唯一权限就是送货，其他需要密码的场合，他都没有权限。

这样的场景下就需要设计一套授权机制，基本的思路如下：

第一步，门禁系统的密码输入器下面，增加一个按钮，叫做"获取授权"。快递员需要首先按这个按钮，去申请授权。

第二步，他按下按钮以后，屋主（也就是我）的手机就会跳出对话框：有人正在要求授权。系统还会显示该快递员的姓名、工号和所属的快递公司。

我确认请求属实，就点击按钮，告诉门禁系统，我同意给予他进入小区的授权。

第三步，门禁系统得到我的确认以后，向快递员显示一个进入小区的令牌（access token）。令牌就是类似密码的一串数字，只在短期内（比如七天）有效。

第四步，快递员向门禁系统输入令牌，进入小区。

有人可能会问，为什么不是远程为快递员开门，而要为他单独生成一个令牌？这是因为快递员可能每天都会来送货，第二天他还可以复用这个令牌。另外，有的小区有多重门禁，快递员可以使用同一个令牌通过它们。

在互联网的场景中，也是相同的设计，也就是oauth的实现思路了。首先，居民小区就是储存用户数据的网络服务。比如，微信储存了我的好友信息，获取这些信息，就必须经过微信的"门禁系统"。其次，快递员（或者说快递公司）就是第三方应用，想要穿过门禁系统，进入小区。最后，我就是用户本人，同意授权第三方应用进入小区，获取我的数据。

简单说，OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

为什么要使用令牌而不是直接让第三方使用我们的账号和密码登录。原因如下：

（1）令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计就是使用令牌的优点，授权码在生效的范围之内，可以执行所有被授权的操作，当他人得到你的令牌后，就可以伪装你的身份进行操作，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。这也是为什么令牌的有效期，一般都设置得很短的原因。

oauth授权机制的实现

oauth使用了四种方式来实现为第三方应用授权，其中也包括使用密码的方式。这四种方式分别为：

授权码（authorization-code）
隐藏式（implicit）
密码式（password）：
客户端凭证（client credentials）

授权码

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。授权步骤如图所示。

第三方应用可以被用户授权的前提是该第三方应用需要向开放平台进行申请，并通过开放平台的审核，用户才能够将在开放平台的信息交给第三方应用。例如，我们自己开发了一个网站，我希望自己的用户可以使用他们的微信进行登录，我就需要当腾讯开放平台申请并等待审核，审核成功后按照oauth授权机制那样实现各个接口，以此完成开放平台的微信登录授权。审核成功后，会得到一个appid(client_id)以及secret_key，需要作为授权过程中的凭证，开放平台以此识别是我们的应用而不是其他应用的用户进行授权，同时也是保证数据安全。发放access-token时不会被其他用户获取。

有了以上的准备工作，用户才能使用开放平台的账号登录，而第三方应用会最后收到开放平台用于授权的access-token随机字符串，这样，第三方应用就可以通过获取的该用户的access-token访问该用户在开放平台权限范围内的数据。

简单总结授权码方式获取授权的整个过程：

用户向第三方应用请求，需要使用开放平台的账号登录，开放平台将用户的请求重定向到开放平台的授权接口。也就是开放平台的url，并在该url后拼接参数，提交给开放平台验证以及保存未来的回调地址。请求的参数如下：

response_type：表示授权类型，必选项，使用授权码模式指定为code即可，看下面的实例
client_id：表示第三方的ID，有了改id，开放平台就知道是哪个第三方应用想要改用户的数据
redirect_uri：第三方的一个接口url，第三方未来的将从这个url的参数中获取到一个code值，通过该code第三方可以向开放平台获取token。
scope：表示第三方想申请的权限范围。用户的数据在开放平台中有不同的访问前线，第三方指定自己想要获取哪一层权限。
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

开放平台收到该授权请求后，向发起请求的用户返回是否确认授权的页面。
用户确认授权后，开放平台同样使用重定向的方式访问第三方应用url，并携带一个code。（为什么不直接返回access-token是因为access-token需要拼接到url尾部，并且返回用户端，经过用户的浏览器到达第三方应用，这个access-token 对用户是可见的，用户的网络环境无法得知，从而可能被他人获取导致该access-token丢失。所以放回的只是一个code，而这个code即使丢失也没关系）
用户重定向通过访问了第三方应用，第三方应用从而获取到了url中code，随后第三方应用访问开放平台的接口，携带code，client_id等信息，获取到access_token。
- 请求的参数
  - grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
  - code：表示上一步获得的授权码，必选项。
  - redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
  - client_id：表示客户端ID，必选项。
- 开放平台返回的数据中参数：
  - access_token：返回一个访问令牌值。
  - token_type：返回该令牌的类型，该值大小写不敏感，可以是bearer类型或mac类型。
  - expires_in：返回该令牌的过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
  - refresh_token：返回一个更新令牌使用的token，上面token过期后，用来获取下一次的访问令牌
  - scope：表示实际授权的权限范围，如果与客户端申请的范围一致，此项可省略。

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

简化模式

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。oauth就规定了第二种方式，允许直接向前端颁发令牌。也就是简化了上面的过程，将返回code的步骤中的参数，替换为直接返回access_token即可。所以步骤大致如下

用户向第三方应用请求，需要使用开放平台的账号登录，开放平台将用户的请求重定向到开放平台的授权接口，url中携带上述的参数，只是将respose_type更改为token，参数如下。
- response_type
- client_id
- redirect_uri
- scope
- state
开放平台收到该授权请求后，向发起请求的用户返回是否确认授权的页面。
用户确认授权，开放平台生成access_token，并将其拼接到redirect_uri后作为参数，并返回重定向，前端由此得到了access_token。

密码式

如果你高度信任某个应用，oauth也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。

第三方应用要求用户提供一个用户名密码，提交到第三方应用的后台。
然后第三方使用这个用户名密码作为参数，访问开放平台获取access_key

　https://oauth.b.com/token?
  　　grant_type=password&          # 指定密码模式
  　　username=USERNAME&
  　　password=PASSWORD&
  　　client_id=CLIENT_ID

开放平台验证身份通过后，直接给出令牌。这时不需要重定向跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，第三方应用直接拿到令牌。

这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

客户端模式

客户端模式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，服务商向客户端提供访问令牌。

客户端向指定接口发送请求，携带自己appid，response_type指定为clientcredentials即可。
开放平台返回一个令牌，返回的消息如下：

  HTTP/1.1 200 OK
     Content-Type: application/json;charset=UTF-8
     Cache-Control: no-store
     Pragma: no-cache

     {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "example_parameter":"example_value"
     }

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

使用令牌

第三方应用得到access_token后，每次访问开放平台获取该用户的数据时候，携带该参数即可，具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

POST /path/to HTTP/1.1
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Authorization: ACCESS_TOKEN       # 添加该头

这样开放平台验证该值即可

更新令牌

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

具体方法是，B开放平台颁发令牌的时候，一次性颁发两个令牌(access_token 和 refresh_token)，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，获取新的access_token 和 refresh_token