概述

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

OAuth2角色

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

OAuth2 协议流程

OAuth2包含四种授权模式：

授权码模式；
隐式/简化授权模式；
密码模式；
客户端模式。
Resource Owner 与 Client 之间，资源所有者向Client发起认证请求， Client再返回认证授权信息。
Client 收到 Resource Owner 的认证请求后，会去Authorization Server 申请访问令牌， Authorization Server会让Client 进行认证，通过之后会返回Access Token。
Client 拿到 Authorization Server 的 Acceess Token , 访问Resource Server，Resource Server 验证之后，返回被保护的资源信息。
Resource Server 可以通过JWT在本地进行验证，也可以访问 Authorization Server，对Client 的请求的合法性进行验证。

OAuth2 授权码模式

客户端携带 client_id, scope, redirect_uri, state 等信息引导用户请求授权服务器的授权端点下发 code。
授权服务器验证客户端身份，验证通过则询问用户是否同意授权（此时会跳转到用户能够直观看到的授权页面，等待用户点击确认授权）。
假设用户同意授权，此时授权服务器会将 code 和 state（如果客户端传递了该参数）拼接在 redirect_uri 后面，以302(重定向)形式下发 code。
客户端携带 code, redirect_uri, 以及 client_secret 请求授权服务器的令牌端点下发 access_token。
授权服务器验证客户端身份，同时验证 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 隐式/简化模式

资源拥有者（用户）通过代理（WEB浏览器）访问客户端程序，发起简化模式认证。
客户端（Client）向认证服务器（Auth Server）发起请求，此时客户端携带了客户端标识（client_id）和重定向地址（redirect_uri）。
客户端（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 密码模式

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

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

2、令牌响应：

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

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

OAuth2 客户端模式

此模式最为简单直接，由客户端直接发起请求。
客户端与服务器信赖度较高，服务端根据请求直接认证返回token信息。
客户端（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，跨区域，需要暴露外网的情况下，不推荐采用此方案，因为需要保障数据的安全性。

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

深入浅出单点登录---2、解决方案
设计方案-Cookie 概述用户登录之后, 将认证信息存储至Cookie,当再次访问本服务或者访问其他应用服务时,直接从Cookie中传递认证信息,进行鉴权处理. 问题如何保障Cookie内用户 ...
深入浅出单点登录（SSO）
1. 摘要 ( 注意:请仔细看下摘要,留心此文是否是您的菜,若浪费宝贵时间,深感歉意!!!) SSO这一概念由来已久,也是相当普遍的一种身份验证设计,网络上对应不同场景的SSO解决方案比比皆是,从简单 ...
深入浅出单点登录---1、什么是单点登录
SSO单点登录什么是单点登录随着互联网大数据不断发展,应用服务的不断增多,单点登录越来越能够凸显其作用.单点登录 SSO(Single Sign On),顾名思义就是单个节点登录,全局使用.是目前 ...
nginx -- 设置单点登录 sso oidc oauth
这个开源项目可以找到你想要的: https://github.com/vouch/vouch-proxy ? 转载于:https://www.cnblogs.com/mafeng/p/10922910 ...
集成公司内部的多个子系统（兼容B/S和C/S），实现单点登录功能的多系统的统一入口功能...
有一句话也挺有意思的,一直在模仿但从未超越过,文章里的技术也都是相对简单的技术,但是实实在在能解决问题,提高效率. 现在人都懒得瞎折腾,能多简单就多简单,谁都不希望总是做一些重复的工作,我们反复登录多 ...
浅谈单点登录SSO实现方案 | StartDT Tech Lab 06
写在前面这是奇点云全新技术专栏「StartDT Tech Lab」的第6期. 在这里,我们聚焦数据技术,分享方法论与实战.一线的项目经历,丰富的实践经验,真实的总结体会-滑到文末,可以看到我们的往期 ...
多维系统下单点登录深入详解
多维系统下单点登录深入详解 1. 从淘宝天猫的单点登录说起 1.1 SSO单点登录 1.2 淘宝天猫登录场景解析 2. 单点登录之整体解决方案 2.1 设计方案-Cookie 2.2 设计方案-分布式 ...
[原创]django+ldap+memcache实现单点登录+统一认证
前言由于公司内部的系统越来越多,为了方便用户使用,通过django进行了单点登录和统一认证的尝试,目前实现了django项目的单点登录和非django项目的统一认证,中间波折挺多,涉及的技术包括dj ...
统一用户单点登录系统
see also:http://www.ibmtech.com.cn/dandian.html 统一用户单点登录的基本原理一般来说,每个应用系统都拥有独立的用户信息管理功能,用户信息的格式.命名与存 ...

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

概述