授权类型 rf_security和oauth2的关系

1. 前言

OAuth 2.0 规范来自 RFC6749。看了《Spring 微服务实战》对OAuth 2.0 的介绍后还是觉得存在一些翻译的问题。现在结合RFC6749一起重新梳理下。

1.1. 一个场景：o-stock 实现获取微信头像。

• 结论性的东西全部来自于该文档。
• 本文是主要以获取微信头像作为模型，对Oauth2.0知识点进行梳理和理解。
• 重点关注授权码授权模式。
• 借《Spring 微服务实战》的项目名 o-stock （对应Oauth2.0中的client）

1.2. 本文不进行中文对照翻译，需要的话看

• 中文译文1
• 中文译文2

2. OAuth 2.0 授权码模式 天然适合 Web 后端技术栈

RFC6749 定义 OAuth 2.0 目前只建立在HTTP协议上。并多次提到user-agen可以交给浏览器扮演，授权码模式十分适合有独立服务器的Web 服务器。

2.1. OAuth 2.0 授权码模式解决了什么问题？

从 o-stock来看

• 留住新用户，新客户可能不想在 o-stock注册，但是或许有使用微信登录的冲动。

从微信 的角度看

• 更多开发者选择微信，那么潜在的用户粘性就增大，但是微信要维护 authorization server 和 resource server 的角色，有不少io的开销。

从行业规范看

• 服务器不需要用户的微信用户名、密码，用户信息更加安全。
• 是一种已被验证的可靠流程，开发者不用再重复造轮子。

2.2. 授权码模式要点

• 微信的 authorization server 不可能给所有o-stock 提供三方登录的功能，那么就要要求o-stock要在微信的 authorization server 上注册
• RFC6749规定，授权码模式下，o-stock不能保存用户的微信密码，取而代之的由是 authorization server 向 o-stock 颁发 code。
• o-stock 需要在微信的 authorization server 持有登录凭证（要让 authorization server 认识自己），带上code和登录客户端登录凭证，请求 authorization server 后可以获取access_token
• access_token 是代替微信密码的最终产物，这个令牌可以在o-stock 保存，o-stock 可用于获取用户头像。

3. RFC6749 未交代的前置因素

• o-stock 需要在微信的 authorization server 进行注册 （ipad上写字，由于膜的原因，比较潦草）
  

4. 以浏览器为切入点理解微信的授权活动

拉文档里的图，现在把user-agen当作浏览器

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

   Note: The lines illustrating steps (A), (B), and (C) are broken into
   two parts as they pass through the user-agent.

                     Figure 3: Authorization Code Flow

4.1. 用户委托浏览器，向微信发起身份验证的GET请求

Note: RFC6749 并没有规范黑色线的具体实现，但是规定了红色线提交参数的具体要求

• 红色的线条可以对照官网给的例子

授权请求：（/authorize 是微信端的url）
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
    Host: server.example.com

4.2. 微信确认身份，委托浏览器颁发code （跟4.3.合并成一幅图）

• 浏览器用重定向的方式告诉o-stock用户的授权请求被微信接纳，用code表示这次接纳的证据。

授权响应：（微信感知到用户同意授权，借浏览器重定向的能力向服务器颁发code）
     HTTP/1.1 302 Found
     Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

4.3. 微信收到o-stock申请access_token的请求，验证身份和请求入口后颁发

授权令牌请求：
     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

值得一提的 Authorization: Basic

Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
也就是上文第一幅图给出的微信token, 这个需要o-stock自己存储维护。网上很多资料都说要携带client_id 和 client_secret，但是官网的这份代码明显没有。原因是czZCaGRSa3F0MzpnWDFmQmF0M2JW 已经能让微信识别出该请求是o-stock发起的，并且规范中也说明了授权码模式，client在已认证的情况下可以不提供client_id ，更不用说client_secret

授权令牌响应：
     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"
     }

4.4. access_token 续期

令牌续期：
     POST /token HTTP/1.1
     Host: server.example.com
     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
     Content-Type: application/x-www-form-urlencoded

     grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

5. 后记

至此，RFC6749 的授权流程已经交代完了。使用access_token 去微信的 resource server 就能获取头像了。整个授权流程其实可以不包含resource server ，resource server 后续可以跟o-stock打交道。o-stock 可以存储access_token 。在基于Oauth2.0之上又拓展了一种OIDC 用于增强认证流程（RFC6749并没有交代认证流程），该规范可以实现单点登录，此时o-stock存储OIDC规范下的id_token不失为一种更好的实现，后续搞清楚了思想再写一篇单点登录的博客记录一下。

今天的文章授权类型 rf_security和oauth2的关系分享到此就结束了，感谢您的阅读。