Day 9:Spring Security Oauth2 JWT

学习目标

  • 用户认证分析
  • 认证技术方案了解
  • SpringSecurity Oauth2.0入门
  • 用户授权认证开发

1 用户认证分析

1558173244406

上面流程图描述了用户要操作的各个微服务,用户查看个人信息需要访问客户微服务,下单需要访问订单微服务,秒杀抢购商品需要访问秒杀微服务。每个服务都需要认证用户的身份,身份认证成功后,需要识别用户的角色然后授权访问对应的功能。

1.1 认证与授权

身份认证

用户身份认证即用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问。常见的用户身份认证表现形式有:用户名密码登录,指纹打卡等方式。说通俗点,就相当于校验用户账号密码是否正确。

用户授权

用户认证通过后去访问系统的资源,系统会判断用户是否拥有访问资源的权限,只允许访问有权限的系统资源,没有权限的资源将无法访问,这个过程叫用户授权。

1.2 单点登录

1558173244406

用户访问的项目中,至少有3个微服务需要识别用户身份,如果用户访问每个微服务都登录一次就太麻烦了,为了提高用户的体验,我们需要实现让用户在一个系统中登录,其他任意受信任的系统都可以访问,这个功能就叫单点登录。

单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务整合的解决方案之一。 SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。

2 认证技术方案

2.1 单点登录技术方案

分布式系统要实现单点登录,通常将认证系统独立抽取出来,并且将用户身份信息存储在单独的存储介质,比如: MySQL、Redis,考虑性能要求,通常存储在Redis中,如下图:

1558175040643

登陆流程:

1. 用户第一次登陆,认证系统将登陆信息(token)存到 redis 中,并返还一个令牌给用户
2. 用户使用其他微服务时,把令牌一起提交
3. 认证系统开始认证令牌是否有效,是否在 redis 中能找到相应信息

单点登录的特点是:

  1. 认证系统为独立的系统。
  2. 各子系统通过Http或其它协议与认证系统通信,完成用户认证。
  3. 用户身份信息存储在Redis集群。

Java中有很多用户认证的框架都可以实现单点登录:

  • Apache Shiro.
  • CAS
  • Spring security CAS

2.2 Oauth2认证

OAuth(开放授权)是一个开放标准,允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容,OAuth2.0是OAuth协议的延续版本。

2.2.1 Oauth2认证流程

第三方认证技术方案最主要是解决认证协议的通用标准 问题,因为要实现 跨系统认证,各系统之间要遵循一定的接口协议。
OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。同时,任何第三方都可以使用OAUTH认证服务,任何服务提供商都可以实现自身的OAUTH认证服务,因而OAUTH是开放的。业界提供了OAUTH的多种实现如PHP、JavaScript,Java,Ruby等各种语言开发包,大大节约了程序员的时间,因而OAUTH是简易的。互联网很多服务如Open API,很多大公司如Google,Yahoo,Microsoft等都提供了OAUTH认证服务,这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。
Oauth 协议目前发展到2.0版本,1.0版本过于复杂,2.0版本已得到广泛应用。
参考:https://baike.baidu.com/item/oAuth/7153134?fr=aladdin
Oauth 协议:https://tools.ietf.org/html/rfc6749
下边分析一个Oauth2认证的例子,黑马程序员网站使用微信认证的过程:

1562394786067

1.客户端请求第三方授权

用户进入黑马程序的登录页面,点击微信的图标以微信账号登录系统,用户是自己在微信里信息的资源拥有者。

1558175450281

点击“用QQ账号登录”出现一个二维码,此时用户扫描二维码,开始给黑马程序员授权。

1558175557482

2.资源拥有者同意给客户端授权

资源拥有者扫描二维码表示资源拥有者同意给客户端授权,微信会对资源拥有者的身份进行验证, 验证通过后,QQ会询问用户是否给授权黑马程序员访问自己的QQ数据,用户点击“确认登录”表示同意授权,QQ认证服务器会 颁发一个授权码,并重定向到黑马程序员的网站。

1558175838653

3.客户端获取到授权码,请求认证服务器申请令牌 此过程用户看不到,客户端应用程序请求认证服务器,请求携带授权码。

4.认证服务器向客户端响应令牌 认证服务器验证了客户端请求的授权码,如果合法则给客户端颁发令牌,令牌是客户端访问资源的通行证。 此交互过程用户看不到,当客户端拿到令牌后,用户在黑马程序员看到已经登录成功。

5.客户端请求资源服务器的资源 客户端携带令牌访问资源服务器的资源。 黑马程序员网站携带令牌请求访问微信服务器获取用户的基本信息。

6.资源服务器返回受保护资源 资源服务器校验令牌的合法性,如果合法则向用户响应资源信息内容。 注意:资源服务器和认证服务器可以是一个服务也可以分开的服务,如果是分开的服务资源服务器通常要请求认证 服务器来校验令牌的合法性。

Oauth2.0认证流程如下: 引自Oauth2.0协议rfc6749 https://tools.ietf.org/html/rfc6749

1558175981680

Oauth2包括以下角色:

1、客户端 本身不存储资源,需要通过资源拥有者的授权去请求资源服务器的资源,比如:畅购在线Android客户端、畅购在 线Web客户端(浏览器端)、微信客户端等。

2、资源拥有者 通常为用户,也可以是应用程序,即该资源的拥有者。

3、授权服务器(也称认证服务器) 用来对资源拥有的身份进行认证、对访问资源进行授权。客户端要想访问资源需要通过认证服务器由资源拥有者授 权后方可访问。

4、资源服务器 存储资源的服务器,比如,畅购网用户管理服务器存储了畅购网的用户信息等。客户端最终访问资源服务器获取资源信息。

2.2.2 Oauth2在项目的应用

Oauth2是一个标准的开放的授权协议,应用程序可以根据自己的要求去使用Oauth2,本项目使用Oauth2实现如 下目标:

1、畅购访问第三方系统的资源

2、外部系统访问畅购的资源

3、畅购前端(客户端) 访问畅购微服务的资源。

4、畅购微服务之间访问资源,例如:微服务A访问微服务B的资源,B访问A的资源。

2.3 Spring security Oauth2认证解决方案

本项目采用 Spring security + Oauth2完成用户认证及用户授权,Spring security 是一个强大的和高度可定制的身份验证和访问控制框架,Spring security 框架集成了Oauth2协议,下图是项目认证架构图:

微信截图_20201008144643

1、用户请求认证服务完成认证。

2、认证服务下发用户身份令牌,拥有身份令牌表示身份合法。

3、用户携带令牌请求资源服务,请求资源服务必先经过网关。

4、网关校验用户身份令牌的合法,不合法表示用户没有登录,如果合法则放行继续访问。

5、资源服务获取令牌,根据令牌完成授权。

6、资源服务完成授权则响应资源信息。

3 Security Oauth2.0入门

3.1 Oauth2授权模式

3.1.1 Oauth2授权模式

Oauth2有以下授权模式:

1.授权码模式(Authorization Code)[常用]
2.隐式授权模式(Implicit)[不常用]
3.密码模式(Resource Owner Password Credentials)[常用]
4.客户端模式(Client Credentials)[不常用]

3.1.2 授权码授权实现

上边例举的黑马程序员网站使用QQ认证的过程就是授权码模式,流程如下:

1、客户端请求第三方授权

2、用户(资源拥有者)同意给客户端授权

3、客户端获取到授权码,请求认证服务器申请 令牌

4、认证服务器向客户端响应令牌

5、客户端请求资源服务器的资源,资源服务校验令牌合法性,完成授权

6、资源服务器返回受保护资源

(1)申请授权码

请求认证服务获取授权码:

Get请求:
http://localhost:9001/oauth/authorize?client_id=changgou&response_type=code&scop=app&redirect_uri=http://localhost

参数列表如下:

client_id:客户端id,和授权配置类中设置的客户端id一致。 
response_type:授权码模式固定为code 
scop:客户端范围,和授权配置类中设置的scop一致。 
redirect_uri:跳转uri,当授权码申请成功后会跳转到此地址,并在后边带上code参数(授权码)

首先跳转到登录页面:

1565035634997

输入账号和密码,点击Login。 Spring Security接收到请求会调用UserDetailsService接口的loadUserByUsername方法查询用户正确的密码。 当前导入的基础工程中客户端ID为changgou,秘钥也为changgou即可认证通过。

接下来进入授权页面:

1565035586067

点击Authorize,接下来返回授权码: 认证服务携带授权码跳转redirect_uri,code=k45iLY就是返回的授权码

1558181855325

(2)申请令牌

拿到授权码后,申请令牌。 Post请求:http://localhost:9001/oauth/token 参数如下:

grant_type:授权类型,填写authorization_code,表示授权码模式 
code:授权码,就是刚刚获取的授权码,注意:授权码只使用一次就无效了,需要重新申请。 
redirect_uri:申请授权码时的跳转url,一定和申请授权码时用的redirect_uri一致。 

此链接需要使用 http Basic认证。 什么是http Basic认证? http协议定义的一种认证方式,将客户端id和客户端密码按照“客户端ID:客户端密码”的格式拼接,并用base64编 码,放在header中请求服务端,一个例子: Authorization:Basic WGNXZWJBcHA6WGNXZWJBcHA=WGNXZWJBcHA6WGNXZWJBcHA= 是用户名:密码的base64编码。 认证失败服务端返回 401 Unauthorized。

以上测试使用postman完成:

http basic认证:

1558182132328

1558182177167

客户端Id和客户端密码会匹配数据库oauth_client_details表中的客户端id及客户端密码。

点击发送: 申请令牌成功

1562408718454

返回信如下:

access_token:访问令牌,携带此令牌访问资源 
token_type:有MAC Token与Bearer Token两种类型,两种的校验算法不同,RFC 6750建议Oauth2采用 Bearer Token(http://www.rfcreader.com/#rfc6750)。 
refresh_token:刷新令牌,使用此令牌可以延长访问令牌的过期时间。 
expires_in:过期时间,单位为秒。 
scope:范围,与定义的客户端范围一致。    
jti:当前token的唯一标识

(3)令牌校验

Spring Security Oauth2提供校验令牌的端点,如下:

Get: http://localhost:9001/oauth/check_token?token= [access_token]

参数:

token:令牌

使用postman测试如下:

1562409096845

如果令牌校验失败,会出现如下结果:

1562409180948

如果令牌过期了,会如下如下结果:

1562409507493

(4)刷新令牌

刷新令牌是当令牌快过期时重新生成一个令牌,它于授权码授权和密码授权生成令牌不同,刷新令牌不需要授权码 也不需要账号和密码,只需要一个刷新令牌、客户端id和客户端密码。

测试如下: Post:http://localhost:9001/oauth/token

参数:

grant_type: 固定为 refresh_token

refresh_token:刷新令牌(注意不是access_token,而是refresh_token)

1562409616911

3.1.3 密码授权实现

(1)认证

密码模式(Resource Owner Password Credentials)与授权码模式的区别是申请令牌不再使用授权码,而是直接 通过用户名和密码即可申请令牌。

测试如下:

Post请求:http://localhost:9001/oauth/token

参数:

grant_type:密码模式授权填写password

username:账号

password:密码

并且此链接需要使用 http Basic认证。

即使是密码授权,也要在后台输入客户端ID和客户端密码

4 资源服务授权

4.1 资源服务授权流程

(1)传统授权流程

1562479275302

资源服务器授权流程如上图,客户端先去授权服务器申请令牌,申请令牌后,携带令牌访问资源服务器,资源服务器访问授权服务校验令牌的合法性,授权服务会返回校验结果,如果校验成功会返回用户信息给资源服务器,资源服务器如果接收到的校验结果通过了,则返回资源给客户端。

传统授权方法的问题是用户每次请求资源服务,资源服务都需要携带令牌访问认证服务去校验令牌的合法性,并根 据令牌获取用户的相关信息,性能低下。

(2)公钥私钥授权流程

1562406193809

传统的授权模式性能低下,每次都需要请求授权服务校验令牌合法性,我们可以利用公钥私钥完成对令牌的加密,如果加密解密成功,则表示令牌合法,如果加密解密失败,则表示令牌无效不合法,合法则允许访问资源服务器的资源,解密失败,则不允许访问资源服务器资源。

上图的业务流程如下:

1、客户端请求认证服务申请令牌
2、认证服务生成令牌认证服务采用非对称加密算法,使用私钥生成令牌。
3、客户端携带令牌访问资源服务客户端在Http header 中添加: Authorization:Bearer 令牌。
4、资源服务请求认证服务校验令牌的有效性资源服务接收到令牌,使用公钥校验令牌的合法性。
5、令牌有效,资源服务向客户端响应资源信息

4.2 公钥私钥

在对称加密的时代,加密和解密用的是同一个密钥,这个密钥既用于加密,又用于解密。这样做有一个明显的缺点,如果两个人之间传输文件,两个人都要知道密钥,如果是三个人呢,五个人呢?于是就产生了非对称加密,用一个密钥进行加密(公钥),用另一个密钥进行解密(私钥)

4.2.1 公钥私钥原理

张三有两把钥匙,一把是公钥,另一把是私钥。

1562470657125

张三把公钥送给他的朋友们----李四、王五、赵六----每人一把。

1562470847506

李四要给张三写一封保密的信。她写完后用张三的公钥加密,就可以达到保密的效果。

1562471063950

张三收信后,用私钥解密,就看到了信件内容。这里要强调的是,只要张三的私钥不泄露,这封信就是安全的,即使落在别人手里,也无法解密。

1562471429501

张三给李四回信,决定采用"数字签名"。他写完后先用Hash函数,生成信件的摘要(digest)。张三将这个签名,附在信件下面,一起发给李四。

1562472383322

李四收信后,取下数字签名,用张三的公钥解密,得到信件的摘要。由此证明,这封信确实是张三发出的。李四再对信件本身使用Hash函数,将得到的结果,与上一步得到的摘要进行对比。如果两者一致,就证明这封信未被修改过。

1562472956514

5 认证开发

5.1 需求分析

用户登录的流程图如下:

1562481462105

执行流程:

1、用户登录,请求认证服务 
2、认证服务认证通过,生成jwt令牌,将jwt令牌及相关信息写入cookie 
3、用户访问资源页面,带着cookie到网关 
4、网关从cookie获取token,如果存在token,则校验token合法性,如果不合法则拒绝访问,否则放行 
5、用户退出,请求认证服务,删除cookie中的token 

5.2 认证服务

5.2.1 认证需求分析

认证服务需要实现的功能如下:

1、登录接口

前端post提交账号、密码等,用户身份校验通过,生成令牌,并将令牌写入cookie。

2、退出接口 校验当前用户的身份为合法并且为已登录状态。 将令牌从cookie中删除。

1558224020588

5.2.3 业务层

1562486044874

如上图,我们现在实现一个认证流程,用户从页面输入账号密码,到认证服务的Controller层,Controller层调用Service层,Service层调用OAuth2.0的认证地址,进行密码授权认证操作,如果账号密码正确了,就返回令牌信息给Service层,Service将令牌信息给Controller层,Controller层将数据存入到Cookie中,再响应用户。

登陆总结:

参数传递:
1.账号 username=szitheima
2.密码 password=szitheima
3.授权方式 grant_type=password

header 传递:
4. Basic Base64(客户端ID:客户端秘钥)

Q.E.D.

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

Live in the future, then build what's missing.