体系大数据工程师2022版2.0升级版

序 到目前为止，易哥已经带你了解了Spring Security的主要功能，并分析了这些内容的底层实现原理。希望你能有所收获。 但是在安全认证领域，还有一个非常重要的授权机制——OAuth 2.0 oauth2.0，而且OAuth 2.0 OAuth 2.0和Spring Security经常一起使用，两者之间的关系可以说是“重点在孟，重点在孟”的搭售关系。所以，为了进一步掌握Spring安全，这里再来一个OAuth 2.0 oauth2.0协议。 OAuth2.0 OAuth2.0不是Spring安全框架的一部分，但是两者经常一起使用，所以我要先普及一下OAuth2.0的内容。毕竟OAuth 2.0的内容相当难懂。 一. OAuth2.0简介 1.oauth 2.0概述 我们来看看RFC6749中对OAuth2.0的定义，如下图所示:

简单来说，OAuth2.0是一种授权机制，在其中引入了一个授权层，可以分离出客户端和资源拥有者两种不同的角色。资源所有者同意客户端(第三方应用)的请求后，资源服务器可以向客户端颁发一个短期访问令牌来替换密码，客户端可以使用这个令牌来请求有限的资源数据。所以OAuth2.0的核心是给第三方应用颁发令牌。 2.发展2。OAuth2.0 oauth(开放授权)-oauth2.0，这是一个关于oauth2.0的协议标准，所谓的oauth2.0是指它是OAuth协议的第2版，但是与之前的OAuth1.0协议不兼容，也就是现在OAuth1.0协议已经完全废止。 那么OAuth1.0协议为什么会被废除呢？先简单说一下OAuth协议的发展。 2007年12月，OAuth协议诞生，2010年4月，被IETF(国际互联网工程任务组)认可并作为认证和授权的标准发布。但是这个OAuth1.0协议有一个致命的缺陷，就是它的签名逻辑特别复杂，开发的时候让程序员极其恶心。而且OAuth1.0的授权流程非常简单，漏洞很大，很容易被黑客攻击。于是在2012年10月，IETF更新发布了OAuth2.0协议。该版本摒弃了之前复杂的数字签名和加密方案，采用HTTPS作为安全措施，降低了程序员的开发难度。但是OAuth2.0协议和OAuth1.0协议互不兼容，所以现在我们在开发的时候，都是采用OAuth2.0协议，而不是OAuth1.0协议。 3.OAuth2.0函数 从上一节我们知道OAuth是一个关于oauth2.0的协议，它实际上是一个服务提供者授权第三方应用获得资源所有者部分访问权限的授权机制。一般来说，OAuth协议允许用户在不向第三方应用提供密码的情况下获取用户数据等基本信息。在整个授权过程中，第三方应用可以在不获取用户密码的情况下获得用户部分资源的使用权，所以OAuth是一个安全的开发协议。 例如，当我们登录CSDN时，我们可以使用CSDN的注册帐户，或者第三方帐户(QQ、微信、微博等)。)进行登录，如下所示:

例如，我们选择用QQ帐户登录CSDN。

此时，我们可以打开QQ扫码，或者点击我们的QQ头像，这样我们就可以使用QQ帐户登录CSDN网站。在这个过程中，我们其实不用担心我们的QQ密码会泄露给CSDN，因为CSDN无法获取我们的QQ密码。 在这个登录过程中，CSDN是相对于QQ的第三方应用，QQ是服务商。QQ内部会有一个认证服务器作为专门的授权中心，QQ用户的用户名、头像等信息都属于资源。这些资源可能存储在专用资源服务器上，也可能直接存储在QQ的认证服务器上。当CSDN通过QQ认证后，可以获得QQ上用户的昵称、头像、性别等信息，让使用QQ的用户登录CSDN的网站，避免了用户重复注册的过程。 4.OAuth2.0使用场景 根据上一小节，我们可以总结OAuth2.0的使用场景，大致如下:

第三方应用登录:比如使用QQ、微博、微信授权登录其他网站或app。 分布式或微服务项目中的授权:开发Java分布式或微服务时，将后端业务拆分成几个服务。在服务之间或者前端之间进行请求时，可以使用OAuth2.0进行安全认证的认证和授权。

二。OAuth2.0的核心概念(要点) 1.核心概念 另外，从以上章节中，我们也知道了OAuth2.0的几个核心概念，具体如下:

客户端/第三方应用程序:获取用户信息。如果我们用QQ账号登录CSDN网站，那么CSDN就是一个第三方应用或者QQ的客户端。 服务提供商:提供外部请求的服务器，比如上面提到的QQ。 资源所有者:资源的所有者。首先要明确“资源”的含义，指的是我们请求的各种URL接口和数据。这里的资源所有者是登录的用户。 授权服务器:认证服务器，即服务提供商(如QQ)用来处理认证的服务器。 服务器:资源服务器，即服务提供商存储用户资源的服务器。它可以是与身份验证服务器相同的服务器，也可以是不同的服务器。 访问令牌:访问令牌，客户端使用它来请求资源服务器(API)的资源。访问令牌通常是短暂的。

2.令牌和密码 在OAuth2.0中提到了令牌的概念，那么什么是令牌呢？密码和我们平时用的密码有什么区别？实际上，OAuth中的令牌与密码具有相同的功能，可以控制用户是否可以访问系统，但也有一些不同。

Token是短期的，到期会自动失效，用户无法自行修改；一般密码都是长期有效的，除非用户修改，否则不会更改。 资源所有者可以吊销令牌，令牌将立即失效；密码一般不允许被他人撤销。 令牌有一定的授权范围，密码一般是完全权限。

注意: token的出现不仅让第三方应用获得了权限，而且可以随时控制，不会危及系统安全。但只要知道令牌，就可以进入系统。一般系统不会再确认你的身份，所以令牌一定要保密。泄露令牌的后果与泄露密码的后果是一样的。这也是为什么令牌的有效期一般设置的比较短的原因。 三。OAuth2.0授权流程(要点) 在了解了OAuth2.0中的各种基本概念之后，我们需要弄清楚OAuth2.0的授权流程，以便于我们后面按照这个授权流程进行开发。 1.授权流程概述

OAuth 2.0的运行过程如下，摘自RFC 6749。

这里，我们以QQ账号登录CSDN网站为例，给大家讲一下OAuth2.0的授权执行流程:

(a)用户(资源拥有者)打开CSDN(客户端)的网站后，CSDN(客户端)向用户(资源拥有者)要求授权； (二)。如果用户(资源所有者)同意，给CSDN(客户端)授权； (三)。CSDN(客户端)使用上一步获得的授权向QQ的认证授权服务器申请访问令牌访问令牌； (四)。QQ的认证授权服务器对CSDN(客户端)进行认证，确认无误后同意发放接入令牌接入令牌； (E)。CSDN(客户端)使用访问令牌向QQ的资源服务器申请获得一些受保护的资源； (f)在确认访问令牌正确无误后，QQ的资源服务器同意向CSDN(客户端)开放受保护的资源。

2.授权流程的详细说明

第一步:点击选择QQ，登录CSDN官网。 当我们点击图标选择QQ登录时，我们实际上向CSDN服务器发送了一条消息。 Graph.qq.com/oauth2.0/sh…YPE = QQ的请求，CSDN服务器会响应一个302重定向地址，指向QQ授权登录。这个访问会携带一个pcAuthCallback，这样在QQ授权成功后，浏览器可以再次发起这个回调的请求，这样QQ就知道授权后返回哪个页面了。 第二步:跳转到QQ登录页面，输入用户名和密码，然后点击授权并登录。 然后浏览器跳转到重定向地址并访问www.qq.com/authorize?. c…* * .

第三步:跳回CSDN页面并成功登录。 这一步后面的过程其实是最繁琐的，但是用户完全察觉不到。 QQ授权服务器判断登录成功后，将页面重定向到之前CSDN发送的回调地址并附加代码授权码，然后跳转到QQ认证服务器发起新的请求，获取AccessToken令牌。令牌获取成功后，CSDN服务器会用获取的令牌换取用户信息，最后将用户信息存储起来并返回到浏览器的主页视图。直到这个OAuth2.0授权结束。 四。OAuth2.0的授权模式(重点) 在解释完OAuth2.0的授权流程后，哥哥再介绍另一个重要概念，即OAuth2.0的授权方式。 RFC 6749标准中定义了四种授权许可，即OAuth2.0有四种方式获得令牌。开发时可以选择最适合自己的，向第三方应用发放令牌。这四种授权方式如下:

授权码模式(授权码) 简化模式(隐式) 密码(资源所有者密码凭据) 客户端凭据(客户端凭据)

1.授权码模式 授权码模式是指第三方应用首先申请一个授权码，然后使用授权码获取访问令牌的方式。该模式是功能最全、流程最严格的授权模式，也是开发中最常用、最安全的授权模式。它适用于那些有后端的Web应用。例如，当我们用QQ信息登录CSDN网站时，采用的是授权码模式。授权码由前端申请，令牌存储在后端，与资源服务器的所有通信都在后端完成，这样前后端是分离的，避免了令牌的泄露。授权码模式的执行过程可以分为以下四个步骤:

接下来，我将分别详细解释这四个步骤。 (1).用户请求客户端A， 客户端A将用户定向到认证服务器B以请求授权码。假设用户同意授权，认证服务器B会将用户定向到客户端A事先指定的URI”(重定向URI)，并附上授权码。 https://b.com/oauth/authorize? 响应类型=代码& 客户端标识=客户端标识& 重定向uri =回调URL& 范围=读取 复制代码 例如，当我们使用QQ登录CSDN网站时，我们获得了代码授权代码的url: https://graph.qq.com/oauth2.0/show?哪个=登录 &display=pc & client _ id = 100270988899 & response _ type =代码 & redirect _ uri = https://passport . csdn . net/account/log in？pcAuthType=qq & state =测试 复制代码

Response_type:授权类型，必选项，定值代码；； Client_id: client id，必选，表示告诉认证服务器b是谁发起的请求； Redirect_uri:可选，是认证服务器B接受或拒绝请求后的回调URL Scope:可选，表示需要的授权范围(此处只读)； 状态:客户端状态。

(2).客户端A接收授权码code， 附加前面的“重定向URI”参数，向认证服务器b申请令牌:GET /oauth/token？response _ type = code & client _ id = test & redirect _ uri =重定向页面链接，请求成功后返回代码授权码。通常，有效时间为10分钟。 https://a.com/callback?代码=授权代码 复制代码 (3)客户端A向认证服务器B发起申请令牌的请求， b会检查授权码并重定向URI，确认后返回访问令牌和刷新令牌POST /oauth/token给客户端a，response _ type = authorization _ code & code = splxlobezqqybys 6 wxsbia & redirect _ uri = redirect页面链接。 https://b.com/oauth/token? 客户端标识=客户端标识& 客户端秘密=客户端秘密& 授权类型=授权代码& 代码=授权_代码& redirect _ uri =回调_URL 复制代码 (4)认证服务器B收到请求后， 将发出一个令牌并将一段JSON数据发送到redirect_uri指定的URL: { “访问令牌”:“访问令牌”， " token_type ":"载体"， " expires_in":2592000， "刷新令牌":"刷新令牌"， “范围”:“读取”， 【uid】:100101， "信息":{...} } 复制代码 2.简化模型 隐式授权类型，有些Web应用只有前端没有后端，所以令牌只能存储在前端浏览器中。因此，RFC 6749还规定了第二种授权方法，允许令牌直接颁发给前端。由于令牌是在浏览器中直接应用于认证服务器，跳过了“授权码”这一步，所以称为“隐藏(授权码)隐式”或隐式授权模式。 隐式授权模式下的客户端一般是指用户的浏览器，通过重定向将访问令牌传递给用户的浏览器，然后通过浏览器的JavaScript代码获取访问令牌。这种授权方式的所有步骤都在浏览器中完成，不经过第三方应用的服务器，访问令牌直接暴露在浏览器端。令牌对访问者是可见的，客户端不需要认证，所以可能导致访问令牌被黑客获取。这种模式适用于不需要高安全性的应用程序，并且只适用于需要临时访问的场景。

程序:

(a)客户端将用户指引到认证服务器； (b)用户决定是否授权给客户； (c)假设用户给予授权，认证服务器将用户定向到客户端指定的“重定向URI ”,并将访问令牌包括在URI的散列部分中； (d)浏览器向资源服务器发送请求，该请求不包括在先前步骤中接收的散列值； (e)。资源服务器返回一个网页，其中包含获取哈希值中的令牌的代码； (f)浏览器执行在先前步骤中获得的脚本来提取令牌； (g)。浏览器将令牌发送给客户端。

请求URL: 获取/授权？response _ type = token & client _ id = s6bhdrkqt 3 & state = XYZ & redirect _ uri = https % 3A % 2F % 2f客户端% 2e示例%2Ecom%2Fcb

HTTP/1.1

主持人:server.example.com 复制代码 与授权码模式相比，用户的登录过程是一样的，只是在授权成功后的重定向中，授权码模式携带一个认证码，客户端通过认证码申请访问令牌。在隐式授权模式下，访问令牌作为URL的哈希部分直接传递给浏览器，哈希部分专门用来指导浏览器的行为。比如浏览器页面定位的锚点，可以通过hash属性来确定。 注意 简化的授权方式是直接把令牌传到前端，这样很不安全。所以这种授权方式适用于一些安全性要求不高的场景，令牌的有效期必须很短，一般在会话期间。当浏览器关闭时，令牌会失效。 3.用户名密码模式 密码模式(resource owner password credentials grant)，客户端提供专用页面，然后用户向客户端提供自己的用户名和密码，客户端利用这些信息向“服务提供者”请求授权。在这种模式下，用户必须将其用户名和密码提供给客户端，但客户端不得存储密码。这种授权模式适合对客户端信任度高的用户，一般不支持刷新令牌。

执行步骤:

(一)。用户向客户端提供用户名和密码； (二)。客户端将用户名和密码发送给认证服务器，并向后者请求令牌； (c)在认证服务器确认没有错误之后，它向客户端提供访问令牌；

响应信息: POST /token HTTP/1.1 主持人:server.example.com 授权:基本czzcagrsa 3 f 0 mzpnwdfqmf 0 m2 jw 内容类型:application/x-www-form-urlencoded grant _ type = password & username = John doe & password = a3 ddj 3w 复制代码 注意 用户名授权需要用户给出自己的用户名/密码，这显然是有风险的，所以只适用于其他授权方式无法使用的情况，而且必须是用户高度信任的应用。 4.客户端模式 客户端模式意味着客户端以自己的名义而不是以用户的名义向“服务提供者”发起认证。严格来说，客户端模式不属于OAuth2.0框架要解决的问题。在这种模式下，用户直接向客户端注册，客户端请求“服务提供者”以自己的名义提供服务。其实不存在授权问题。

在客户端授权模式下，客户端通常提前向授权服务器申请公钥和私钥，然后通过这些密钥信息向授权服务器申请访问令牌，从而获得资源服务器提供的资源，如常见的微信公众平台、支付宝支付平台授权等。这种模式适合没有前端的命令行应用，即在命令行下请求令牌。

执行步骤:

(一)。客户端向认证服务器发起身份认证，并索要访问令牌； (b)在认证服务器确认它是正确的之后，它向客户端提供访问令牌。

在步骤A中，客户端发送的HTTP请求包括以下参数:

Granttype:表示授权类型，这里的值固定为“clientcredentials”，这是必需的。 Scope:表示权限范围，可选。

响应信息: POST /token HTTP/1.1 主持人:server.example.com

授权:基本czzcagrsa 3 f 0 mzpnwdfqmf 0 m2 jw 内容类型:application/x-www-form-urlencoded

grant _ type =客户端凭据

#grant_type参数等于client_credentials，表示采用凭证类型。 #client_id和client_secret用于B确认a的身份。 复制代码 注意 这样给出的令牌是针对第三方应用，而不是用户，也就是有可能多个用户共享同一个令牌。

download：体系大数据工程师2022版2.0升级版