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"
}
文章来源：https://www.toymoban.com/news/detail-516335.html
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不失为一种更好的实现，后续搞清楚了思想再写一篇单点登录的博客记录一下。文章来源地址https://www.toymoban.com/news/detail-516335.html
到了这里，关于【安全】 阅读 RFC6749 及理解 Oauth2.0 下的授权码模式的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
