SpringCloud-OAuth2（一）：基础篇

关于Oauth2 的详细介绍官网地址：https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

1：什么是OAuth2

首先，OAuth不是API或服务：它是开放的授权标准，任何人都可以实现。

更具体地说，OAuth是应用程序可用于向客户端应用程序提供“安全委托访问”的标准。

OAuth通过HTTPS进行工作，并使用访问令牌（而不是凭据）对设备，API，服务器和应用程序进行授权。

2：为什么要用OAuth2

OAuth是作为对直接身份验证模式的响应而创建的。该模式通过HTTP基本身份验证而闻名，在该系统中，提示用户输入用户名和密码。基本身份验证仍用作服务器端应用程序API身份验证的原始形式：用户发送API密钥ID和密码，而不是随每个请求向服务器发送用户名和密码。在使用OAuth之前，网站会提示您直接在表单中输入您的用户名和密码，然后他们将以您的身份登录到您的数据（例如您的Gmail帐户）。这通常称为密码反模式。

为了为Web创建更好的系统，创建了用于单点登录（SSO）的联合身份。在这种情况下，最终用户与他们的身份提供者进行对话，并且身份提供者生成一个加密签名的令牌，并将其交给应用程序以对用户进行身份验证。该应用程序信任身份提供者。

工作流程图：

3：OAuth2 组件

①：Resource Owner: 资源拥有者。

②：Resource Server: 提供资源访问的资源服务器

③：Client: 访问服务器资源的客户端

④：Authorization Server: 认证服务器

4：OAuth Token

访问令牌是客户端用来访问资源服务器（API）的令牌。

①：access_token

存在过期时间，可能是12个小时，由Authorization Server 颁发并决定它的过期时间。

②：refresh_token

一般比access_token的过期时间长点，用来重新获取access_token。

---

默认的Oauth Token 是UUID 形式存在的。当然我们也可以将 token 的结构以JWT的形式颁发给客户端。

4.1：JWT简单介绍

什么是JWT？

JSON Web Token（JWT）是⼀个开放的⾏业标准（RFC 7519），它定义了⼀种简介的、⾃包含的协议

格式，⽤于 在通信双⽅传递json对象，传递的信息经过数字签名可以被验证和信任。JWT可以使⽤

HMAC算法或使⽤RSA的公 钥/私钥对来签名，防⽌被篡改。

JWT 通常分为三部分，中间用 . 隔开，分别为 header、payload、signature。

---

①：header

头部包括令牌的类型（即JWT）及使⽤的哈希算法（如HMAC SHA256或RSA），例如:

{
 "alg": "HS256",
 "typ": "JWT"
}

②：payload

第⼆部分是负载，内容也是⼀个json对象，它是存放有效信息的地⽅，它可以存放jwt提供的现成

字段，⽐ 如：iss（签发者）,exp（过期时间戳）, sub（⾯向的⽤户）等，也可⾃定义字段。 此部

分不建议存放敏感信息，因为此部分可以解码还原原始内容。

{
 "expire": "1234567890",
 "username": "ZhangSan",
 "role":["admin"]
}

③：Signature

第三部分是签名，此部分⽤于防⽌jwt内容被篡改。 这个部分使⽤base64url将前两部分进⾏编

码，编码后使⽤点（.）连接组成字符串，最后使⽤header中声明 签名算法进⾏签名。

HMACSHA256(
 base64UrlEncode(header) + "." +
 base64UrlEncode(payload),
 secret)

---

打开 jwt.io官网 官网便有展示的例子：

4.2：JWT 与 session 的区别

在很多情况下，我们会采用session共享的技术方案去解决集群条件下登录状态的问题。比如Spring-Session框架就很好解决了这个问题。

那么为什么还需要JWT呢？

区别一：是否需要存储在服务端？

session共享需要存放在redis或者其他分布式缓存中，以保证每个服务节点能共享session。

而JWT并不需要存储在服务端，客户端可以将token存放在Cookie或者LocalStorage中，并在发送请求的时候带上就行，服务端只是将JWT解密出来并校验而已。

区别二：对于跨系统的sso谁更出色？

个人认为是JWT更出色，因为A系统颁发的token，B系统只需要具备识别token的机制即可，不需要和A系统进行交互即可认证（前提是A、B系统的用户资料需同步）。

5：OAuth2 四种授权模式

5.1：Authrization Code Grant Type

A：用户发送请求到 Auth Server，请求需携带客户端凭证、redirect_uri、授权类型(code) 信息。

B：Auth Server校验客户端凭证是否通过，通过则调到登录页，不通过则返回错误。

C：用户在登录页输入用户名+密码，再请求到 Auth Server 。

D：Auth Server校验用户名+密码是否正确，不正确返回错误，正确调到redirect_uri 地址并在地址上拼接上code。

E：用户拿到 code 调用/oauth/token 接口带上code作为参数，以授权码模式（authorization_code）换取 token。

F：Auth Server 对code进行校验（code具备过期时间，且只能使用一次，无论换token是否成功或者失败），失败返回错误，成功则发放token。

G：拿到token之后用户便是一个Resource Owner，可以带上token 访问自己的资源。如访问属于自己的用户资料。

H：用户对token进行鉴权，通过之后返回正确的响应体，否则返回错误。

5.2：Password Grant Type

A：用户发送携带客户端凭证、用户名密码、授权类型（password） 信息的请求到Auth Server。

B：Auth Server 先校验客户端凭证是否正确，不正确返回错误。

C：再校验用户名密码是否合法，不合法返回错误。

D：B、C全部通过，Auth Server 发放token给客户端。

E：拿到token之后用户便是一个Resource Owner，可以带上token 访问自己的资源。如访问属于自己的用户资料。

F：用户对token进行鉴权，通过之后返回正确的响应体，否则返回错误。

5.3：Client Credentials Grant Type

A：用户发送携带客户端凭证、授权类型（client_credentials）的请求到Auth Server。

B：服务端进行校验之后，不通过则返回错误，通过则发放token（不返回refresh_token）。

5.4：Implicat Grant Type

A：用户发送请求到 Auth Server，请求需携带客户端凭证、redirect_uri、授权类型(token) 信息。

B：Auth Server 对客户端凭证进行校验，失败返回错误，成功重定向到授权页。

C：用户选择具体的scope，点击 Approval/Deny 按钮，并发送认证请求到 Auth Server。

D：用户若是点击了Deny 再发送请求，服务端返回错误信息，用户若是点了Approval 按钮，则返回可用的token（token未失效则是发放旧的token）。

---

授权码模式（authorization_code）和简易模式（implicat）中参数解析：

名称	作用
response_type	表示授权类型，必选项，authorization_code 模式值为"code"，implicat模式值为"token"。
client_id	表示客户端的ID，必选项。
redirect_uri	表示重定向URI，可选项。
scope	表示申请的权限范围，可选项。
state	可选项，表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。