【安全】阅读 RFC6749 及理解 Oauth2.0 下的授权码模式

本文主要是介绍【安全】阅读 RFC6749 及理解 Oauth2.0 下的授权码模式，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

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 intotwo 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.1Host: server.example.com

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

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

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

在这里插入图片描述

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

授权令牌请求：POST /token HTTP/1.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_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 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: 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.1Host: server.example.comAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type: application/x-www-form-urlencodedgrant_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不失为一种更好的实现，后续搞清楚了思想再写一篇单点登录的博客记录一下。