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

概述

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={任意值} // 可选项
1
2
3
4
5

2、授权响应参数：

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

3、令牌请求：

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

4、令牌响应：

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

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={任意值} // 可选项
1
2
3
4
5

2、授权响应参数：

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

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

OAuth2 密码模式

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

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

2、令牌响应：

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

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

OAuth2 客户端模式

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

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

2、令牌响应：

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

增强Token技术解决方案

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