[Java知识库]SpringSecurity、Oauth2、JWT

SpringSecurity

一、SpringSecurity简介

1.1.安全框架概述

? 什么是安全框架?解决系统安全问题的框架。如果没有安全框架，我们需要手动处理每个资源的访问控制，非常麻烦。使用安全框架，我们可以通过配置的方式实现对资源的访问限制。

1.2.常用安全框架

• Spring Security: Spring家族一员。是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI(控制反转Inversion of Contro1,DI: Dependency Injectkion依赖注入〉和AOP(面向切面编程〉功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
• Apache Shiro:一个功能强大且易于使用的Java安全框架,提供了认证,授权,加密,和会话管理。

1.3. Spring security简介

概述

? Spring Security是一个高度自定义的安全框架。利用Spring loC/DI和AOP功能，为系统提供了声明式安全访问控制功能，减少了为系统安全而编写大量重复代码的工作。使用Spring Secruity的原因有很多，但大部分都是发现了javaEE的Servlet规范或EJB规范中的安全功能缺乏典型企业应用场景。同时认识到他们在WAR 或EAR 级别无法移植。因此如果你更换服务器环境，还有大量工作去重新配置你的应用程序。使用Spring Security解决了这些问题，也为你提供许多其他有用的、可定制的安全功能。正如你可能知道的两个应用程序的两个主要区域是"认证′和"授权”(或者访问控制)。这两点也是Spring Security重要核心功能。"认证”，是建立一个他声明的主体的过程(一个"主体"一般是指用户，设备或一些可以在你的应用程序中执行动作的其他系统)，通俗点说就是系统认为用户是否能登录。"授权"指确定一个主体是否允许在你的应用程序执行一个动作的过程。通俗点讲就是系统判断用户是否有权限去做某些事情。

二、SpringSecurity中的CSRF

从刚开始学习Spring Security时，在配置类中一直存在这样一行代码: http.csrf().disable();如果没有这行代码导致用户无法被认证。这行代码的含义是:关闭csrf 防护。

2.1、什么是CSRF

• CSRF (Cross-site request forgery)跨站请求伪造，也被称为“OneClick Attack”或者Session Riding。通过伪造用户请求访问受信任站点的非法请求访问。
• 跨域:只要网络协议，ip地址，端口中任何一个不相同就是跨域请求。
• 客户端与服务进行交互时，由于http协议本身是无状态协议，所以引入了cookie进行记录客户端身份。在cookie中会存放session id用来识别客户端身份的。在跨域的情况下，session id可能被第三方恶意劫持，通过这个session id向服务端发起请求时，服务端会认为这个请求是合法的，可能发生很多意想不到的事情。

2.2、Spring security中的CSRF

从Spring Security4开始CSRF防护默认开启。默认会拦截请求。进行CSRF处理。CSRF为了保证不是其他第三方网站访问，要求访问时携带参数名为_csrf值为token(token在服务端产生)的内容，如果token和服务端的token匹配成功，则正常访问。

三、Oauth2认证

3.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

3.2. 角色

• 客户端

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

• 资源拥有者

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

• 授权服务器（也称认证服务器)

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

• 资源服务器

  存储资源的服务器，比如，网站用户管理服务器存储了网站用户信息，网站相册服务器存储了用户的相册信息，微信的资源服务存储了微信的用户信息等。客户端最终访问资源服务器获取资源信息。

3.3. 常用术语

• 客户凭证(client credentials):客户端的clientld和密码用于认证客户
• 令牌(tokens):授权服务器在接收到客户请求后，颁发的访问令牌
• 作用域(scopes):客户请求访问令牌时，由资源拥有者额外指定的细分权限(permission)

3.4. 令牌类型

• 授权码:仅用于授权码授权类型，用于交换获取访问令牌和刷新令牌
• 访问令牌:用于代表一个用户或服务直接去访问受保护的资源
• 刷新令牌:用于去授权服务器获取一个刷新访问令牌
• BearerToken:不管谁拿到Token都可以访问资源，类似现金
• Proof of Possession(PoP) Token:可以校验client是否对Token有明确的拥有权

3.5.特点

优点:

? 更安全，客户端不接触用户密码，服务器端更易集中保护

? 广泛传播并被持续采用

? 短寿命和封装的token

? 资源服务器和授权服务器解耦

? 集中式授权，简化客户端

? HTTP/JSON友好，易于请求和传递token

? 考虑多种客户端架构场景

? 客户可以具有不同的信任级别

缺点:

? 协议框架太宽泛，造成各种实现的兼容性和互操作性差

? 不是一个认证协议，本身并不能告诉你任何用户信息。

http://localhost:8080/oauth/authorize?responsetype=code&clientid=admin&redirecturi=http://www.baidu.com&scope=all

http://localhost:8080/oauth/authorize?response%20type=code&client%20id=admin&redirect%20uri=http://www.baidu.com&scope=all

四、JWT

4.1.常见的认证机制

4.1.1.HTTP Basic Auth

HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password，简言之，Basic Auth是配合RESTfulAPI使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用HTTP BasicAuth。

4.1.2.Cookie Auth

Cookie认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象;通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie的expire time使cookie在一定时间内有效。

4.1.3.OAuth

OAuth (开放授权,Open Authorization)是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。如网站通过微信、微博登录等，主要用于第三方登录。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频)。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

这种基于OAuth的认证机制适用于个人消费者类的互联网产品，如社交类APP等应用，但是不太适合拥有自有认证权限管理的企业应用。

缺点:过重。

4.14.Token Auth

使用基于Token的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的:

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个Token，再把这个Token发送给客户端
4. 客户端收到Token 以后可以把它存储起来，比如放在Cookie里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的Token
6. 服务端收到请求，然后去验证客户端请求里面带着的Token，如果验证成功，就向客户端返回请求的数据

比第一种方式更安全，比第二种方式更节约服务器资源，比第三种方式更加轻量。

具体，Token Auth的优点(Token机制相对于Cookie机制又有什么好处呢? )：

1. 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
2. 无状态(也称:服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
3. 更适用CDN:可以通过内容分发网络请求你服务端的所有资料(如: javascript，HTML,图片等)，而你的服务端只要提供API即可.
4. 去耦:不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可公
5. 更适用于移动应用:当你的客户端是一个原生平台(iOS,Android，Windows 10等)时，Cookie是不被支持的(你需要通过Cookie容器进行处理)，这时采用Token认证机制就会简单得多。
6. CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
7. 性能:一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算的Token验证和解析要费时得多.
8. 不需要为登录页面做特殊处理:如果你使用Protractor做功能测试的时候，不再需要为登录页面做特殊处理.
9. 基于标准化:你的API可以采用标准化的JSON Wweb Token (JWT).这个标准已经存在多个后端库（.NET,Ruby,Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft) .

4.2.JWT简介

4.2.1.什么是JWT

? JSON Web Token (JWT)是一个开放的行业标准(RFC 7519)，它定义了一种简介的、自包含的协议格式，用于在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任。JWT可以使用HMAC算法或使用RSA的公钥/私钥对来签名，防止被篡改。

官网: https://jwt.io/

标准: https://tools.ietf.org/html/rfc7519

JWT令牌的优点:

1. jwt基于json，非常方便解析。
2. 可以在令牌中自定义丰富的内容，易扩展。
3. 通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。4.资源服务使用WT可不依赖认证服务即可完成授权。

缺点:

1. JWT令牌较长，占存储空间比较大。

4.2.2.JWT组成

? 一个WT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。

1. 头部(Header)

   头部用于描述关于该WT的最基本的信息，例如其类型(即WT)以及签名所用的算法(如HMAC SHA256或RSA)等。这也可以被表示成一个JSON对象。

2. 负载(Payload)

   第二部分是负载，就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分:

3. 签证、签名(signature)

   jwt的第三部分是一个签证信息，这个签证信息由三部分组成:

   1. header (base64后的)
   2. payload (base64后的)
   3. secret(盐，一定要保密)

   这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分:
   ?

一、SpringSecurity简介

1.1.安全框架概述

? 什么是安全框架?解决系统安全问题的框架。如果没有安全框架，我们需要手动处理每个资源的访问控制，非常麻烦。使用安全框架，我们可以通过配置的方式实现对资源的访问限制。

1.2.常用安全框架

• Spring Security: Spring家族一员。是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI(控制反转Inversion of Contro1,DI: Dependency Injectkion依赖注入〉和AOP(面向切面编程〉功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
• Apache Shiro:一个功能强大且易于使用的Java安全框架,提供了认证,授权,加密,和会话管理。

1.3. Spring security简介

概述

? Spring Security是一个高度自定义的安全框架。利用Spring loC/DI和AOP功能，为系统提供了声明式安全访问控制功能，减少了为系统安全而编写大量重复代码的工作。使用Spring Secruity的原因有很多，但大部分都是发现了javaEE的Servlet规范或EJB规范中的安全功能缺乏典型企业应用场景。同时认识到他们在WAR 或EAR 级别无法移植。因此如果你更换服务器环境，还有大量工作去重新配置你的应用程序。使用Spring Security解决了这些问题，也为你提供许多其他有用的、可定制的安全功能。正如你可能知道的两个应用程序的两个主要区域是"认证′和"授权”(或者访问控制)。这两点也是Spring Security重要核心功能。"认证”，是建立一个他声明的主体的过程(一个"主体"一般是指用户，设备或一些可以在你的应用程序中执行动作的其他系统)，通俗点说就是系统认为用户是否能登录。"授权"指确定一个主体是否允许在你的应用程序执行一个动作的过程。通俗点讲就是系统判断用户是否有权限去做某些事情。

二、SpringSecurity中的CSRF

从刚开始学习Spring Security时，在配置类中一直存在这样一行代码: http.csrf().disable();如果没有这行代码导致用户无法被认证。这行代码的含义是:关闭csrf 防护。

2.1、什么是CSRF

• CSRF (Cross-site request forgery)跨站请求伪造，也被称为“OneClick Attack”或者Session Riding。通过伪造用户请求访问受信任站点的非法请求访问。
• 跨域:只要网络协议，ip地址，端口中任何一个不相同就是跨域请求。
• 客户端与服务进行交互时，由于http协议本身是无状态协议，所以引入了cookie进行记录客户端身份。在cookie中会存放session id用来识别客户端身份的。在跨域的情况下，session id可能被第三方恶意劫持，通过这个session id向服务端发起请求时，服务端会认为这个请求是合法的，可能发生很多意想不到的事情。

2.2、Spring security中的CSRF

从Spring Security4开始CSRF防护默认开启。默认会拦截请求。进行CSRF处理。CSRF为了保证不是其他第三方网站访问，要求访问时携带参数名为_csrf值为token(token在服务端产生)的内容，如果token和服务端的token匹配成功，则正常访问。

三、Oauth2认证

3.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

3.2. 角色

• 客户端

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

• 资源拥有者

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

• 授权服务器（也称认证服务器)

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

• 资源服务器

  存储资源的服务器，比如，网站用户管理服务器存储了网站用户信息，网站相册服务器存储了用户的相册信息，微信的资源服务存储了微信的用户信息等。客户端最终访问资源服务器获取资源信息。

3.3. 常用术语

• 客户凭证(client credentials):客户端的clientld和密码用于认证客户
• 令牌(tokens):授权服务器在接收到客户请求后，颁发的访问令牌
• 作用域(scopes):客户请求访问令牌时，由资源拥有者额外指定的细分权限(permission)

3.4. 令牌类型

• 授权码:仅用于授权码授权类型，用于交换获取访问令牌和刷新令牌
• 访问令牌:用于代表一个用户或服务直接去访问受保护的资源
• 刷新令牌:用于去授权服务器获取一个刷新访问令牌
• BearerToken:不管谁拿到Token都可以访问资源，类似现金
• Proof of Possession(PoP) Token:可以校验client是否对Token有明确的拥有权

3.5.特点

优点:

? 更安全，客户端不接触用户密码，服务器端更易集中保护

? 广泛传播并被持续采用

? 短寿命和封装的token

? 资源服务器和授权服务器解耦

? 集中式授权，简化客户端

? HTTP/JSON友好，易于请求和传递token

? 考虑多种客户端架构场景

? 客户可以具有不同的信任级别

缺点:

? 协议框架太宽泛，造成各种实现的兼容性和互操作性差

? 不是一个认证协议，本身并不能告诉你任何用户信息。

http://localhost:8080/oauth/authorize?responsetype=code&clientid=admin&redirecturi=http://www.baidu.com&scope=all

http://localhost:8080/oauth/authorize?response%20type=code&client%20id=admin&redirect%20uri=http://www.baidu.com&scope=all

四、JWT

4.1.常见的认证机制

4.1.1.HTTP Basic Auth

HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password，简言之，Basic Auth是配合RESTfulAPI使用的最简单的认证方式，只需提供用户名密码即可，但由于有把用户名密码暴露给第三方客户端的风险，在生产环境下被使用的越来越少。因此，在开发对外开放的RESTful API时，尽量避免采用HTTP BasicAuth。

4.1.2.Cookie Auth

Cookie认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象;通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie的expire time使cookie在一定时间内有效。

4.1.3.OAuth

OAuth (开放授权,Open Authorization)是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源(如照片，视频，联系人列表)，而无需将用户名和密码提供给第三方应用。如网站通过微信、微博登录等，主要用于第三方登录。
OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频)。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

这种基于OAuth的认证机制适用于个人消费者类的互联网产品，如社交类APP等应用，但是不太适合拥有自有认证权限管理的企业应用。

缺点:过重。

4.14.Token Auth

使用基于Token的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的:

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个Token，再把这个Token发送给客户端
4. 客户端收到Token 以后可以把它存储起来，比如放在Cookie里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的Token
6. 服务端收到请求，然后去验证客户端请求里面带着的Token，如果验证成功，就向客户端返回请求的数据

比第一种方式更安全，比第二种方式更节约服务器资源，比第三种方式更加轻量。

具体，Token Auth的优点(Token机制相对于Cookie机制又有什么好处呢? )：

1. 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
2. 无状态(也称:服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
3. 更适用CDN:可以通过内容分发网络请求你服务端的所有资料(如: javascript，HTML,图片等)，而你的服务端只要提供API即可.
4. 去耦:不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可公
5. 更适用于移动应用:当你的客户端是一个原生平台(iOS,Android，Windows 10等)时，Cookie是不被支持的(你需要通过Cookie容器进行处理)，这时采用Token认证机制就会简单得多。
6. CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF(跨站请求伪造)的防范。
7. 性能:一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算的Token验证和解析要费时得多.
8. 不需要为登录页面做特殊处理:如果你使用Protractor做功能测试的时候，不再需要为登录页面做特殊处理.
9. 基于标准化:你的API可以采用标准化的JSON Wweb Token (JWT).这个标准已经存在多个后端库（.NET,Ruby,Java,Python, PHP)和多家公司的支持(如:Firebase,Google, Microsoft) .

4.2.JWT简介

4.2.1.什么是JWT

? JSON Web Token (JWT)是一个开放的行业标准(RFC 7519)，它定义了一种简介的、自包含的协议格式，用于在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任。JWT可以使用HMAC算法或使用RSA的公钥/私钥对来签名，防止被篡改。

官网: https://jwt.io/

标准: https://tools.ietf.org/html/rfc7519

JWT令牌的优点:

1. jwt基于json，非常方便解析。
2. 可以在令牌中自定义丰富的内容，易扩展。
3. 通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。4.资源服务使用WT可不依赖认证服务即可完成授权。

缺点:

1. JWT令牌较长，占存储空间比较大。

4.2.2.JWT组成

? 一个WT实际上就是一个字符串，它由三部分组成，头部、载荷与签名。

1. 头部(Header)

   头部用于描述关于该WT的最基本的信息，例如其类型(即WT)以及签名所用的算法(如HMAC SHA256或RSA)等。这也可以被表示成一个JSON对象。

2. 负载(Payload)

   第二部分是负载，就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分:

3. 签证、签名(signature)

   jwt的第三部分是一个签证信息，这个签证信息由三部分组成:

   1. header (base64后的)
   2. payload (base64后的)
   3. secret(盐，一定要保密)

   这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分:
   ?