目录

一、什么是OAuth2

二、OAuth2中的角色

三、认证流程

四、令牌的特点

五、OAuth2授权方式

授权码

隐藏方式

密码方式

凭证方式

---

一、什么是OAuth2.0

概念：第三方授权解决方案

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

举例说明：

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

二、OAuth2中的角色

资源所有者

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

资源服务器

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

客户

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

授权服务器

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

三、认证流程

1.客户发送认证申请给资源所有者

2.资源所有者同意授权

3.客户拿着授权码code，请求认证服务器（oauth2）

4.认证服务器（oauth2）返回一个token令牌给客户

5.客户拿到token令牌请求 资源服务器

6.资源服务器同意客户的登录

四、令牌的特点

使用令牌方式的有点：

• 令牌有时效性，一般都是短期的，且不能修改，密码一般是长期有效的
• 令牌可以由颁发者撤销，且即时生效，密码一把可以不用修改而长期有效
• 令牌可以设定权限的氛围，且使用者无法修改

在使用令牌时需要保证令牌的保密，令牌验证游侠即可加入系统，不会再做其他验证

五、OAuth2授权方式

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

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

授权码

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

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

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

流程如下：

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

https://b.com/oauth/authorize?
 response_type=code&
 client_id=CLIENT_ID&
 redirect_uri=CALLBACK_URL&
 scope=read

• response_type=code，表示使用授权码方式
• client_id=CLIENT_ID，请求者的身份ID
• redirect_uri=CALLBACK_URL， 认证服务器接受请求之后的调转连接，可以根据这个连接将生成的code发送给资源服务器
• scope=read，授权范围为只读

2.页面跳转后，用户登录认证服务器，同意或拒绝资源服务器的授权请求，认证服务器根据上一步的redirect_uri地址，将生成的授权码返回给资源服务器

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

code返回的认证码

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

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 令牌生成后的颁发地址

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

{  
 "access_token":访问令牌,
 "token_type":"bearer",
 "expires_in":过期时间,
 "refresh_token":"REFRESH_TOKEN",
 "scope":"read",
 "uid":用户ID,
 "info":{...}
}

隐藏方式

隐藏方式合适的场景：

当web应用为纯前端应用没有后端，此时必须将令牌放在前端保存，省略了申请授权码的步骤。

1.资源服务器提供连接，跳转到认证服务器

https://b.com/oauth/authorize?
 response_type=token&
 client_id=CLIENT_ID&
 redirect_uri=CALLBACK_URL&
 scope=read

•  response_type=token 表示直接返回令牌
• client_id=CLIENT_ID 客户的身份ID
• redirect_uri=CALLBACK_URL 生成令牌后的回调地址
• scope=read 授权范围，只读

2.用户需要在认证服务器登录，并进行授权， 授权成功后会根据第一步提供的CALLBACK_URL地址返回生成的token

https://a.com/callback#token=ACCESS_TOKEN

这种方式的特点：这种方式不安全，适用于对安全性不高的场景，令牌的有效期一般设置的比较短，通常是会话期间有效，浏览器关闭令牌就时效了

密码方式

非常信任某个应用，将用户名和密码直接告诉应用，应用拿到用户名和密码后直接申请令牌

1. 资源服务器要求用户提供认证服务器的用户名和密码，拿到以后资源服务器向认证服务器申请令牌

https://oauth.b.com/token?
 grant_type=password&
 username=USERNAME&
 password=PASSWORD&
 client_id=CLIENT_ID

•  grant_type=password 认证方式
• username=USERNAME 用户名
• password=PASSWORD 密码
• client_id=CLIENT_ID 客户id

 认证服务器验证身份通过后，直接在响应中发放令牌，资源服务器在响应中获取令牌

凭证方式

这种方式适用于没有前端的命令行应用，通过命令行的方式请求令牌

资源服务器使用命令行向认证服务器发送请求

https://oauth.b.com/token?
 grant_type=client_credentials&
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET

• grant_type=client_credentials 凭证方式
• client_id=CLIENT_ID 客户身份ID
• client_secret=CLIENT_SECRET 认证码

该方式真对的是第三方应用，而不是用户，可以多个用户共享一个令牌