目录

一、什么是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 认证码

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