在今年2月14日的时候，Keycloak 团队宣布他们正在弃用大多数 Keycloak 适配器。其中包括Spring Security和Spring Boot的适配器，这意味着今后Keycloak团队将不再提供针对Spring Security和Spring Boot的集成方案。但是，如此强大的Keycloak，还要用怎么办呢？本文就来聊聊，在最新的Spring Boot 3.1版本之下，如何将Keycloak和Spring Security一起跑起来。
这里所采用的框架与工具版本信息如下：
我在上一篇对资源服务器进行了简单的阐述，让大家对资源服务器的概念有了简单的认识，今天我将用实际例子来演示单体应用改造为Spring Cloud微服务时的资源服务器实现。
以Spring Security实战干货的DEMO为例子，原本它是一个单体应用，认证和授权都在一个应用中使用。改造为独立的服务后，原本的认证就要剥离出去（这个后续再讲如何实现），服务将只保留基于用户凭证（JWT）的访问控制功能。接下来我们将一步步来实现该能力。
最近有个粉丝提了个问题，说他在Spring Security中用JWT做退出登录的时无法获取当前用户，导致无法证明“我就是要退出的那个我”，业务失败！经过我一番排查找到了原因，而且这个错误包括我自己的大部分人都犯过。
之所以要说Session会话，是因为Spring Security默认配置就是有会话的，所以当你登录以后Session就会由服务端保持直到你退出登录。只要Session保持住，你的请求只要进入服务器就可以从ServletRequest中获取到当前的HttpSession，然后会根据HttpSession来加载当前的SecurityContext。相关的逻辑在Spring Security默认的过滤器SecurityContextPersistenceFilter中，有兴趣可以看相关的源码。
各位程序猿小伙伴们，中秋快乐~在节日欢快的气氛中大家是不是还在奋笔疾书、沉浸在学习的海洋中呢？
小编这两天休息在家一直在想一个问题，那就是我们在开发SpringBoot项目的时候，该怎么做好权限认证呢？之前有和小伙伴讨论的时候说起过一些常见的相关框架，例如Shiro或者Spring Security等，但这些框架似乎在运用上存在着各种美中不足的地方，尤其是用起来太过复杂，劝退了不少新手程序猿，让人总觉意犹未尽。
不过呢，就在这个假期里，小编发现了一个新的权限认证框架，总体感觉使用起来简单明了，整体的API设计呢也属上乘，所以赶紧来和大家分享下~
他就是，权限认证框架领域一块璀璨的明珠~~~下面让我们有请：
在开始这篇文章之前，我们似乎应该思考下为什么需要搞清楚Spring Security的内部工作原理？按照第二篇文章中的配置，一个简单的表单认证不就达成了吗？更有甚者，为什么我们不自己写一个表单认证，用过滤器即可完成，大费周章引入Spring Security，看起来也并没有方便多少。对的，在引入Spring Security之前，我们得首先想到，是什么需求让我们引入了Spring Security，以及为什么是Spring Security，而不是shiro等等其他安全框架。我的理解是有如下几点：
前面的部分，我们关注了Spring Security是如何完成认证工作的，但是另外一部分核心的内容：过滤器，一直没有提到，我们已经知道Spring Security使用了springSecurityFillterChian作为了安全过滤的入口，这一节主要分析一下这个过滤器链都包含了哪些关键的过滤器，并且各自的使命是什么。
由于过滤器链路中的过滤较多，即使是Spring Security的官方文档中也并未对所有的过滤器进行介绍，在之前，《Spring Security(二)--Guides》入门指南中我们配置了一个表单登录的demo，以此为例，来看看这过程中Spring Security都帮我们自动配置了哪些过滤器。
上一篇文章《Spring Security(二)--Guides》，通过Spring Security的配置项了解了Spring Security是如何保护我们的应用的，本篇文章对上一次的配置做一个分析。
这是Spring Security入门指南中的配置项：
@Configuration
@EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/", "/home").permitAll()
.anyRequest().authenticated()
.and()
.formLogin()
.loginPage("/login")
.permitAll()
.and()
.logout()
.permitAll();
}
@Autowired
public void configureGlobal(AuthenticationManagerBuilder auth) throws Exception {
auth
.inMemoryAuthentication()
.withUser("admin").password("admin").roles("USER");
}
}
上一篇文章《Spring Security(一)--Architecture Overview》，我们介绍了Spring Security的基础架构，这一节我们通过Spring官方给出的一个guides例子，来了解Spring Security是如何保护我们的应用的，之后会对进行一个解读。
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
</dependencies>
一直以来我都想写一写Spring Security系列的文章，但是整个Spring Security体系强大却又繁杂。陆陆续续从最开始的guides接触它，到项目中看了一些源码，到最近这个月为了写一写这个系列的文章，阅读了好几遍文档，最终打算尝试一下，写一个较为完整的系列文章。
较为简单或者体量较小的技术，完全可以参考着demo直接上手，但系统的学习一门技术则不然。以我的认知，一般的文档大致有两种风格：Architecture First和Code First。前者致力于让读者先了解整体的架构，方便我们对自己的认知有一个宏观的把控，而后者以特定的demo配合讲解，可以让读者在解决问题的过程中顺便掌握一门技术。关注过我博客或者公众号的朋友会发现，我之前介绍技术的文章，大多数是Code First，提出一个需求，介绍一个思路，解决一个问题，分析一下源码，大多如此。而学习一个体系的技术，我推荐Architecture First，正如本文标题所言，这篇文章是我Spring Security系列的第一篇，主要是根据Spring Security文档选择性翻译整理而成的一个架构概览，配合自己的一些注释方便大家理解。写作本系列文章时，参考版本为Spring Security 4.2.3.RELEASE。
上一篇文章中我们介绍了获取token的流程，这一篇重点分析一下，携带token访问受限资源时，内部的工作流程。
还记得我们在第一节中就介绍过了OAuth2的两个核心概念，资源服务器与身份认证服务器。我们对两个注解进行配置的同时，到底触发了内部的什么相关配置呢？
上一篇文章重点介绍的其实是与身份认证相关的流程，即如果获取token，而本节要分析的携带token访问受限资源，自然便是与@EnableResourceServer相关的资源服务器配置了。