深入浅出单点登录---4、基于OAuth实现的统一认证

概述

OAuth2 实质是为第三方应用颁发一个具有时效性的Token令牌，使其他服务或第三方应用能够通过令牌获取相关 资源。 常见的场景： 比如进入某个网站没有账号信息， 但可以通过QQ、微信、支付宝等账号进行登陆， 在这个 登陆过程中采用的就是Oauth2协议； OAUTH2不仅支持认证，还具备授权功能， 比如通过QQ登录获取用户头 像，基本资料等。

OAuth2角色

• resource owner : 资源所有者，具备访问该资源的实体， 如果是某个人， 被称为end-user。
• resources server: 资源服务器，受保护的资源服务器， 具备提供资源能力， 如订单服务， 商品服务等。
• client: 客户端，这并不是指用户，而是对资源服务器发起请求的应用程序，比如前后分离项目， 前端服务访问管理接口， 访问后台业务功能接口。
• authorization server: 授权服务器， 能够给客户端颁发令牌， 这个就是我们上面所讲的统一认证授权服务器。
• user-agent: 用户代理，作为资源所有者与客户端沟通的工具， 比如APP， 浏览器等。

OAuth2 协议流程

OAuth2包含四种授权模式：

1. 授权码模式；

2. 隐式/简化授权模式；

3. 密码模式；

4. 客户端模式。
   

5. Resource Owner 与 Client 之间 ， 资源所有者向Client发起认证请求， Client再返回认证授权信息。

6. Client 收到 Resource Owner 的认证请求后， 会去Authorization Server 申请访问令牌， Authorization Server会让Client 进行认证， 通过之后会返回Access Token。

7. Client 拿到 Authorization Server 的 Acceess Token , 访问Resource Server，Resource Server 验证之后， 返回被保护的资源信息。

8. Resource Server 可以通过JWT在本地进行验证， 也可以访问 Authorization Server， 对Client 的请求的合法性进行验证。

OAuth2 授权码模式

1. 客户端携带 client_id, scope, redirect_uri, state 等信息引导用户请求授权服务器的授权端点下发 code。
2. 授权服务器验证客户端身份，验证通过则询问用户是否同意授权（此时会跳转到用户能够直观看到的授权页面，等待用户点击确认授权）。
3. 假设用户同意授权，此时授权服务器会将 code 和 state（如果客户端传递了该参数）拼接在 redirect_uri 后 面，以302(重定向)形式下发 code。
4. 客户端携带 code, redirect_uri, 以及 client_secret 请求授权服务器的令牌端点下发 access_token。
5. 授权服务器验证客户端身份，同时验证 code，以及 redirect_uri 是否与请求 code 时相同，验证通过后下发 access_token，并选择性下发 refresh_token，支持令牌的刷新。

示例：
1、授权请求：

response_type=code // 必选项 
&client_id={客户端的ID} // 必选项 
&redirect_uri={重定向URI} // 可选项 
&scope={申请的权限范围} // 可选项 
&state={任意值} // 可选项

2、授权响应参数：

code={授权码} // 必填 
&state={任意文字} // 如果授权请求中包含 state的话那就是必填

3、令牌请求：

grant_type=authorization_code // 必填 
&code={授权码} // 必填 必须是认证服务器响应给的授权码 
&redirect_uri={重定向URI} // 如果授权请求中包含 redirect_uri 那就是必填 
&code_verifier={验证码} // 如果授权请求中包含 code_challenge 那就是必填

4、令牌响应：

"access_token":"{访问令牌}", // 必填 
"token_type":"{令牌类型}", // 必填 
"expires_in":{过期时间}, // 任意 
"refresh_token":"{刷新令牌}", // 任意 
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填

OAuth2 隐式/简化模式

1. 资源拥有者（用户）通过代理（WEB浏览器）访问客户端程序，发起简化模式认证。
2. 客户端（Client）向认证服务器（Auth Server）发起请求， 此时客户端携带了客户端标识（client_id）和重定向地址（redirect_uri）。
3. 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
   示例：
   1、授权请求：

response_type=token // 必选项 
&client_id={客户端的ID} // 必选项 
&redirect_uri={重定向URI} // 可选项 
&scope={申请的权限范围} // 可选项 
&state={任意值} // 可选项

2、授权响应参数：

&access_token={令牌信息} // 必填 
&expires_in={过期时间} // 任意 
&state={任意文字} // 如果授权请求中包含 state 那就是必填 
&scope={授权范围} // 如果请求和响应的授权范围不一致就必填

思考：为什么要有授权码和简化模式？看完这两种模式， 可能会有些疑问， 为什么要这么麻烦， 直接一次请求 返回TOKEN不就可以吗？
我们可以看出， 两者主要差别， 是少了code验证环节， 直接返回token了， code验证是客户端与认证服务器在后台进行请求获取， 代理是获取不到TOKEN的， 如果缺少这个环节， 直接返回TOKEN， 相当于直接暴露给所有参 与者， 存在安全隐患， 所以简化模式，一般用于信赖度较高的环境中使用。

OAuth2 密码模式

1. 资源拥有者直接通过客户端发起认证请求。
2. 客户端提供用户名和密码， 向认证服务器发起请求认证。
3. 认证服务器通过之后， 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
   示例：
   1、令牌请求：

grant_type=password // 必填 
&username={用户ID} // 必填 
&password={密码} // 必填 
&scope={授权范围} // 任意

2、令牌响应：

"access_token":"{访问令牌}", // 必填 
"token_type":"{令牌类型}", // 必填 
"expires_in":"{过期时间}", // 任意 
"refresh_token":"{刷新令牌}", // 任意 
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填

此模式简化相关步骤， 直接通过用户和密码等隐私信息进行请求认证， 认证服务器直接返回token， 这需要整个 环境具有较高的安全性。

OAuth2 客户端模式

1. 此模式最为简单直接， 由客户端直接发起请求。
2. 客户端与服务器信赖度较高， 服务端根据请求直接认证返回token信息。
3. 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
   这种模式一般在内部服务之间应用， 授权一次， 长期可用， 不用刷新token。
   示例:
   1、令牌请求：

grant_type=client_credentials // 必填 
client_id={客户端的ID} // 必填 
client_secret={客户端的密钥} // 必填
&scope={授权范围} // 任意

2、令牌响应：

"access_token":"{访问令牌}", // 必填 
"token_type":"{令牌类型}", // 必填 
"expires_in":"{过期时间}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填

增强Token技术解决方案

优势与应用场景
基于Token的鉴权方案，实现方式有多种，增强Token属于其中一种，为什么要采用增强Token方式，它能够解决怎样的问题？
普通Token认证方式，没有附带必要的用户信息，如果要查询，需要再次调用OAuth2的用户资料认证接口，会增加传输开销；JWT虽然能够附带一定用户信息，但受限于长度，存储空间有限； 如果既要保障性能， 又要求能够存储一定的信息，就可以采用增强Token方案，它是将信息存储至Redis缓存中，作为资源服务，接收到Token之后, 可以直接从Redis中获取信息。 它可以适用于微服务架构下，有一定用户信息要求的场景，比如订单服务、资金服务需要获取用户的基本资料，但如果是跨IDC，跨区域，需要暴露外网的情况下，不推荐采用此方案，因为需要保障数据的安全性。