OAuth2.0入门

最新推荐文章于 2024-05-15 03:25:41 发布

糖心何包蛋·

最新推荐文章于 2024-05-15 03:25:41 发布

阅读量518

点赞数

分类专栏：微信小程序文章标签：服务器运维

本文链接：https://blog.csdn.net/hmjcxy/article/details/128834782

版权

微信小程序专栏收录该内容

2 篇文章 0 订阅

订阅专栏

1、什么是OAuth2.0?

OAuth2.0是目前使用非常广泛的授权机制，用于授权第三方应用获取用户的数据。

举例说明：

用户可以通过选择其他登录方式来使用 gitee ，这里就使用到了第三方认证。

来自 RFC 6749

OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。 ...... 资源所有者同意

以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。

oauth2工作原理图：

举例：使用授权码方式来用支付宝登录淘宝

2. OAuth2中的角色

1. 资源所有者

能够授予对受保护资源的访问权限的实体，如果资源的所有者为个人，也被成为最终用户

1. 资源服务器

存储有受保护资源的服务器，能够接受并验证访问令牌，并响应受保护资源的访问请求

1. 客户

需要被授权，然后再访问受保护资源的实体。客户这个术语，并不是特指应用程序，服务器，计算机

等。

1. 授权服务器

验证资源所有者并获取授权成功后，向客户发出访问令牌

3. 认证流程

4. 生活中的Oauth2思维

场景设置：小王出差在外，为家中买了一台空调需要上门安装，小王的老爸老王在家，小王家是小王的

老婆做主，只用获得老婆的许可方能有进入家中。现在空调客服人员需要进到小王家中安装空调。设计

的流程如下：

客服人员发一个进门安装空调的的申请给小王

小王看到了服务人员的申请，在验证了客服人员的公司名称，工号等信息后，同意申请，并发给他

一个授权码

客服人员获取授权码之后，使用授权码去申请进门的令牌，申请发到小王的老婆那里，小王老婆在

验证了授权码之后给客服人员发了一个含有有效期为一天的令牌（小王的老婆可以查看到小王发的

原始验证码）

客服人员拿着令牌到小王家

老王在验证令牌有效后可客服人员进入客厅安装空调，但这个令牌不能进入其他房间。

一天后令牌会过期，如有需要则需要重新申请

上面的过程反应了 OAuth2 认证的典型流程，流程中的角色对应关系

客户 ---> 客服人员

资源所有者 ---> 小王

授权服务器 ---> 小王老婆

资源服务器 ---> 客厅

场景设置2：使用授权码方式登陆淘宝

第一步，进入淘宝登录页面，点击支付宝进行授权

（原理1：点击后，客户(淘宝)向资源所有者(我的支付宝账号)发送认证申请需要返回授权码）

第二步，我用支付宝扫码后同意授权登录

（原理2：资源所有者(我的支付宝)同意授权(允许登录)，返回一个授权码code给客户(淘宝)）

从我们操作表面上看我们只能看见前面两步然后就会直接登录成功实际上oauth2在后台的步骤不止我们所见

并不是我们返回一个授权码给淘宝后就可以登录成功还需要进行如下的步骤：

（原理3：客户(淘宝）拿着授权码code，d请求认证服务器(oauth2)）

（原理4：认证服务器(oauth2)返回一个token令牌给客户(淘宝)）

（原理5：客户(淘宝)拿到token令牌请求资源服务器(支付宝的服务器)）

（原理6：资源服务器(支付宝的服务器)同意客户(淘宝的登录请求)）

第三步：登录成功

5. 令牌的特点

使用令牌方式的优点：

令牌又时效性，一般是短期的，且不能修改，密码一般是长期有效的令牌可以由颁发者撤销，且即时生效，密码一般可以不用修改而长期有效

令牌可以设定权限的范围，且使用者无法修改

在使用令牌时需要保证令牌的保密，令牌验证有效即可进入系统，不会再做其他的验证。

6. OAuth2 授权方式

由于互联网有多种场景， OAuth2 定义了四种获取令牌的方式，可以选择合适与自己的方式

授权码（ authorization-code ）

隐藏式（ implicit ）

密码式（ password ）：

客户端凭证（ client credentials ）

6.1 授权码

第三方应用先申请一个授权码，然后再用该码获取令牌。

最常见的用法，安全性高，适合 web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资

源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

流程如下：

1. 资源服务器提供一个链接，用户点击后就会跳转到认证服务器，授权用户数据给资源服务器使用，

资源服务器提供的连接的示例：

https : //b.com/oauth/authorize?

response_type = code &

client_id = CLIENT_ID &

redirect_uri = CALLBACK_URL &

scope = read

redirect_uri=CALLBACK_URL ，认证服务器接受请求之后的调转连接，可以根据这个连接将生成

的 code 发送给资源服务器

scope=read ，授权范围为只读

1. 页面跳转后，用户登录认证服务器，同意或拒绝资源服务器的授权请求，认证服务器根据上一步的

redirect_uri 地址，将生成的授权码返回给资源服务器。

https : //resouce.com/callback_url?code=AUTHORIZATION_CODE

code 返回的认证码

1. 客户拿到认证码之后，向认证服务器发给请求，申请令牌

https : //b.com/oauth/token?

client_id = CLIENT_ID &

client_secret = CLIENT_SECRET &

grant_type = authorization_code &

code = AUTHORIZATION_CODE &

redirect_uri = CALLBACK_URL

client_id 资源服务器的身份 ID

client_secret=CLIENT_SECRET 安全参数，只能在后端发请求

grant_type=authorization_code 表示授权的方式为授权码

code=AUTHORIZATION_CODE 用来获取令牌的授权码

redirect_uri=CALLBACK_URL 令牌生成后的颁发地址

1. 认证服务器对授权码进行认证，通过后颁发令牌，

{

"access_token" : 访问令牌 ,

"token_type" : "bearer" ,

"expires_in" : 过期时间 ,

"refresh_token" : "REFRESH_TOKEN" ,

"scope" : "read" ,

"uid" : 用户 ID ,

"info" :{ ... }

}