网站微信扫码登录拓展之OAuth2.0

提示：本篇博客对网站微信扫码登录总结文章进行细节补充与拓展

---

OAuth 2.0

一、授权框架与机制

OAuth 2.0 授权框架通过协调资源所有者和HTTP服务之间的批准交互来代表资源所有者或者直接给与第三方应用权限，帮助第三方应用获取用户数据。官方文档link

在传统的客户端-服务器认证模型中，客户端通过向服务器提供用户的认证证书来访问存储在客户端中的用户数据。为了能够向第三方应用提供这些用户数据，用户往往需要将认证证书提供给第三方。这样的行为会造成下面的一些问题：

• 第三方应用会要求将用户的认证证书存储以供未来使用，通常会包括密码
• 服务器会被要求进行密码认证，尽管这一验证通常具有很弱的安全性
• 第三方应用可能在不受到用户控制的情况下过多的获取用户数据。用户将不能限制第三方应用对自己数据访问的时长和数据类型。
• 当用户想要撤销对一个第三方应用的授权时，必须撤销对所有第三方应用的授权。比如修改密码
• 对任何第三方应用程序妥协都会损害用户的密码安全以及改密码保护的所有数据

OAuth 2.0协议能够解决上述麻烦，通过使用acess token：一个字符串规定了具体的访问范围、生命周期与其他的访问属性。服务器在获得用户同意的情况下会将acess token授予给第三方客户端，然后客户端会通过acess token访问存储在服务器中的用户数据。

举个例子，小区住户可以向外卖小哥提供一个短时间的进门许可（access token）来代替提供门禁密码从而让外卖送到门口，当进门许可超过时限后买卖小哥将不能通过这个许可再次进入小区。
协议流程图：

A：客户端要求用户的授权。授权要求能够直接发给用户，或者通过授权服务器作为中转。
B：客户端收到授权许可。
C：客户端向认证服务器展示自己获得的用户授权许可，并要求获得acess token
D：认证客户端、验证用户授权许可，如果有效发送access token给客户端
E：客户端向存储数据的服务器提供access token并要求获得用户数据
F：存储数据的服务器验证acess token，如果有效则服务客户端要求

客户端拿到令牌后，可以向服务器的API请求数据。每个发到API的请求，都必须带有令牌。具体做法是在请求的头信息加入Authorization字段，令牌就放在这个字段里面。

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.xd.com"

OAuth 2.0允许用户自动更新令牌。授权服务器在办法令牌时会一次性颁发两个令牌，一个令牌（acess token）用于获得数据，一个令牌（refresh token）用于更新第一个令牌。
刷新一个过期的acess token：

A. 客户端向授权服务器提供认证授权并要求获得acess token
B. 授权服务器验证授权有效后向客户端传递access token和refresh token
C. 客户端向资源服务器展示令牌然后要求客户数据
D. 资源服务器验证access token，如果有效，处理客户端要求
E. 步骤C和步骤D重复直到access token过期。当access token过期过期后，如果客户端知道acess token过期，则跳到步骤G。否则，客户端会继续调用用户数据
F. 因为access token已经过期无效了，资源服务器会向客户端返回一个无效令牌错误
G. 客户端要求授权服务器的验证并展示refresh token以换取一个新的access token。服务器的验证要求会基于客户端类型和服务器的验证政策
H. 授权服务器通过客户端认证并且验证refresh token，如果有效，生成一个新的acess token（也可生成一个新的refresh token）

二、四种授权方式

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

无论使用哪种方式，第三方应用在申请令牌之前都应该先到系统备案，获得两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。这是为了防止令牌被没有备案过的第三方应用乱用

1.授权码

使用授权码（authorization-code）方式，第三方应用先申请一个授权码，然后用授权码换取令牌。最常用的方法，安全性也最高，常见于有后端的web应用。前后端分开，前端请求获得授权码，令牌存储在后端，后端完成与资源服务器的通信。