一、前言
该章内容其实仍然属于前言，只是对后面Spring Security对各个架构所需要涉及到的相关概念进行讲解，比如在单体式Web-》前后端分离-》Oauth2的一个架构理念以及Spring Security随着架构的演变是如何去改变它的大体用法的，这些我们都会涉及到，但是更详细的内容后面章节将逐一展示。
架构直接影响着为应用程序配置Spring Security的选择；因为安全保障方法取决于我们实现的解决方案，所以Spring Security中的配置也会有所不同。下面我们将讨论一些基于不同架构方式的示例，这些示例中将考虑影响安全保障方法的各种需求。
二、单体式Web应用程序
首先我们要开发一个代表Web应用程序的系统组件。在这个应用程序的开发过程中后台和前端没有直接分离。这类应用程序出现的方式通常是通过普通的servlet流：应用程序接收HTTP请求，然后将HTTP响应发送回客户端。有时候，可为每个客户端提供一个服务器端会话，以便存储更多HTTP请求的特定细节。在本书提供的示例中，我们使用了Spring MVC
那么以上就是Spring MVC流的最小化标识，我们在这里就不往深处说
那么只要有一个会话，就需要考虑前文提到的会话固定漏洞 以及CSRF的可能性。还必须考虑在HTTP会话本身中所存储的内容。
服务器端会话是准持久化的。它们是有状态的数据片段，因此他们的生命周期较长。而他们在内存中驻留的时间越长，它们被访问的统计概率就越大。例如，能够访问堆转储的人可以读取应用程序内部内存中的信息。不要认为获取堆转储有太大的难度！特别是当你在使用Spring Boot开发应用程序时，你可能会发现Actuator也是应用程序的一部分。Spring Boot Actuator是一个很好的工具。根据其配置方式的不同，它可以只返回一个端点调用的堆转储，也就是说，并不一定需要root权限来访问VM才能获得转储文件。
在本例中，回到CSRF方面的漏洞，避免该漏洞的最简单的方法就是使用反CSRF令牌。幸运的是，有了Spring Security，这个功能就可以开箱即用了。默认情况下，CSRF保护和原始CORS的验证都是启用了的。如果确定不想使用它们，则必须手动禁用。对于身份验证和授权，可以选择使用来自Spring Security的隐式登录表单配置。这样，我们就只需要重写登录和注销的外观，并且还可以获得与身份验证和授权配置的默认集成。我们还将免受会话固定的困扰。
如果实现身份验证和授权，这还意味着我们应该拥有一些具有有效凭证的用户。我们可以选择让应用程序管理用户的凭据，或者也可以选择依赖另一个系统来完成这项工作（例如，我们可能希望用户使用其QQ，微信，Gitee凭据进行登录）。在任何一种情况下，Spring Security都可以帮助我们以一种相对简单的方式配置用户管理。可以选择将用户信息存储在数据库中、使用Web服务或者连接到另一个平台。Spring Security架构中使用的抽象使其解耦化了，这样就可以选择适合我们应用程序的任何实现。
三、为前后端分离设计安全性
如今，在Web应用程序的开发中，我们经常看到前端和后端分离的选择，在这些程序中，开发人员使用ReactJS或Vue.js这样的框架开发前端，通过REST端点与后端通信，我们后面也将在这个架构实现应用Spring Security的示例。
如上图，浏览器执行前端应用程序。此应用程序调用后端公开的REST端来执行用户请求的一些操作
在前后端分离架构下，我们通常会避免使用服务器端会话:客户端会话将会替换这些会话，这类系统设计类似与在移动应用中使用的系统设计。运行在Android或iOS操作系统上的应用程序会通过REST端点调用后端。
就安全性而言，还有其他一些方面需要考虑。首先，CSRF和CORS配置通常会更复杂。我们可能要水平地扩展系统，但并不是必须将前端和后端放在同一个服务源点上。对于移动应用，我们甚至无法获悉其服务源点。
作为一种实际的解决方案，最简单但最不理想的方法就是使用HTTP BASIC进行端点身份验证，虽然这种方法很容易理解，并且通常会用于初始的理论身份验证示例，但是它确实存在我们希望避免的漏洞。例如，使用HTTP Basic意味着每次调用时发送凭据。如果该凭据没有加密，浏览器以BASE64编码的方式发送用户名和密码，这样，就可以在每个端点调用的头信息中获取流经网络的凭据。另外，假设凭据代表了已登录的用户，我们就不会希望用户为每个请求都输入他们的凭据。也不希望必须在客户端存储凭据。这种做法是不可取的。
考虑上述原因，我们将介绍一种身份验证和授权的替代方法，即OAuth2。
四、理解Oauth2流程
本节将探讨OAuth2流程的高度概述。主要是关注应用OAuth2的原因，后面我们将详细讨论这个话题。我们当然希望找到一种解决方案，以避免将每个请求的凭据重新发送到后端，并将其存储在客户端，这些情况下，OAuth2流程提供了更好的实现身份验证和授权的方法。
OAuth2框架定义了两个独立的实体：授权服务器和资源服务器。授权服务器的目的是对用户进行授权，并为用户提供一个令牌，该令牌将指定用户可以使用的一组资源权限。实现此功能的后端被称为资源服务器。可以调用的端点则被视作受保护的资源。根据获得的令牌，完成授权后，对于资源的调用则被视作受保护的资源。根据获得的令牌，完成授权后，对于资源的调用可能会被允许也肯能会被拒绝。具体步骤如下图：
(1)用户访问应用程序中的用例（也称为客户端）。应用程序需要调用后端资源。
（2）为了能够调用资源，应用程序首先必须获得访问令牌，因此它需要调用授权服务器来获得该令牌。在请求中，应用程序会在某些情况下发送用户凭据或一个刷新令牌。
（3）如果凭据或刷新令牌正确，则授权服务器将向客户端返回一个（新的）访问令牌
(4)在调用所需的资源时，在对资源服务器的请求的头信息中要使用访问令牌。
令牌其实就是我们老生常谈的token，类似门禁卡，经过身份验证之后，将向调用者提供一个令牌，基于该令牌，调用者可以访问其具有权限的资源。
令牌有固定的生命周期，通常是短期的。当一个令牌过期时，应用程序需要获得一个新的令牌。如果需要，服务器可以在令牌过期之前取消其资格。下面列出这种流程的一些优点：
- 客户端不需要存储用户凭据。访问令牌，以至于刷新令牌是唯一需要保存的访问细节。
- 应用程序不公开用户凭据，这些凭据常常存在于网络上。
- 如果有人截获了一个令牌，我们可以取消该令牌的资格，而不需要使用用户凭据失效。
- 令牌可以由第三方实体使用，从而以用户的名义访问资源，而不必模拟用户。当然，在这种情况下，攻击者可以窃取令牌。但是，由于令牌的生命周期通常较短，因此可以使用此漏洞获取的令牌也是有时间限制的
当然，即使使用OAuth2流程，也不是所有一切都完美了，还需要使其适应应用的程序设计，其中一个问题就是，哪一种是管理令牌的最佳方式？
- 将令牌持节化到应用程序的内存中
- 将令牌持久化到数据库中
- 使用加密签名和JWT（JSON Web Tokens)
版权声明：本文不是「本站」原创文章，版权归原作者所有 | 原文地址: