Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

时间:2022-10-18 11:27:07

基于服务器Session的认证方式:

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

前边说的用户名密码登录、短信登录、第三方登录,都是普通的登录,是基于服务器Session保存用户信息的登录方式。登录信息都是存在服务器的session(服务器的一块内存)里 ,用户通过浏览器访问服务的时候,每一次服务器都会检查浏览器的cookie里有没有JESSIONID,如果不存在JESSIONID服务器会新建一个session,将新建的session的id写到浏览器的cookie里。服务器每次都会从请求里拿出JSESSIONID,然后去找对应的session,然后从session里拿出用户信息。

app、前后端分离

随着技术的发展,新的前端渠道app出现了,而且随着应用部署方式的改变,前后端分离现在也很流行,前后端分离模式下,html就是一种前端的资源,不在和应用服务器部署在一起了,而是单独部署在WebServer上,比如nodejs。前后端分离模式用户访问的是WebServer,由WebServer访问Application Server,WebServer处理ajax请求和渲染返回的数据。这种模式下,访问应用服务器的不再是用户了而是第三方的应用。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

明确一点,如果app和WebServer只要能处理cookie,这种模式还是可以用Cookie+Session认证方式的。但是存在问题:

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

1,开发繁琐:浏览器对cookie已经是内建好的,不需要我们针对cookie写太多代码。app而言,每次关闭再打开app,都需要实例化http客户端发请求,每次实例化http客户端cookie都是空的,需要自己去处理之前cookie存的数据。

2,安全性和客户体验差:cookie 没有特别的校验,JSESSIONID如果被泄露,放在cookie窃取到用户信息。如果通过缩短cookie有效时间解决这个问题,就会出现用户不断登录的情况

3,有些前端技术不支持cookie如微信小程序

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

令牌的方式处理认证信息的存储

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

发给用户一个令牌token,用户每次访问都拿着令牌,来判断用户登录信息权限等,token表现形式就是一个字符串。这样上边说的三个问题就可以解决了,token 不是通过cookie来携带的,而是http请求的参数,在请求头或者普通的参数都行;基于session的JESSIONID是服务器自己生成的,校验也是他自己校验,但是token的生成、校验我们可以自己控制,可以在token上加技术手段来增强安全性,可以实现token 刷新的方式而不会出现用户重复登录,缩短token有效时间增强安全性还保证了用户体验。

用令牌的方式在应用服务器和其他应用之间的认证和授权。这就很自然的联系到了OAuth协议了。OAuth协议就是用token的方式来做认证授权的:

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

前后端分离模式下使用OAuth2协议的结构

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

应用服务器--------------------相当于-------->服务提供商(如第三方登录的微信服务器)

APP、WebServer----------相当于-------->第三方应用  

Spring Security OAuth 简介:

Spring Social 实际上是封装了第三方应用(Client)所要做的大多数事情,拿着Spring Social可以很快开发一个第三方应用来连接想要连接的服务提供商,而Spring Security OAuth和Spring Social 正好相反,Spring Security OAuth 封装了服务提供商的大部分行为,用来快速搭建服务提供商的程序,发放令牌、校验令牌。

要实现服务提供商,其实就是要实现两个服务器 :认证服务器、资源服务器

认证服务器:

  实现四种授权模式:来确认用户身份以及拥有的权限。Spring Security OAuth 里已实现了四种授权模式

  token的生成和存储:根据信息生成令牌token,资源服务器根据token拿资源。OAuth协议没有规定token的具体生成方式,Spring Security OAuth 提供了默认的实现。

资源服务器:

  保护资源,在我们的场景,资源就是Rest 服务。Spring Security 是一系列的过滤器链,Spring Security OAuth就是加了个OAuth2AuthenticationFilter的过滤器,从请求中拿出来发出去的token,根据配置的存储策略从存储里根据token拿出用户信息,根据用户信息是否存在、是否有权限等来判断是否能访问要访问的 服务。

自己实现服务提供商:

要处理的问题是,我们不希望用户走标准的四种授权模式的,如手机号+短信验证码登录方式和标准四种授权模式是对应不上的。我们需要做的是让自定义的认证方式可以嫁接到认证服务器上,让用户通过自己的认证方式也可以调用token 生成的机制生成token发给第三方应用,第三方应用存储这个token ,每次访问服务带上这个token 经过过滤器链上的过滤器通过认证、授权来访问服务。

Spring Security构建Rest服务-1200-SpringSecurity OAuth开发APP认证框架

1,实现一个标准的OAuth2协议中Provider(服务提供商:认证服务器、资源服务器)角色的主要功能

2,重构之前的认证方式,使其支持token

3,自定义 token的生成方式