程序员劝退师的博客

前言这是一篇关于SpringSecurity OAuth2细节对比的文章，我是在同一个授权服的情况下，资源服分别采用不同的TokenStore策略，获取Authentication，准去的说是在获取authentication.getPrincipal()的时候我发现JWTStore 和RedisStore得到的数据是不一样的，那么这就引起了我的好奇心！基于Redis的Store基于JWT的Store接口代码如下两个资源服都有这个一样的接口！ @GetMapping(value = "/g

前言这是我在整合整个系统的时候发现的，一不注意就出了个BUG，说真的SpringSecurity OAuth2细节BUG还真多，这是我第三次整合了！问题就是我在做全局解析Token方案的时候另辟蹊径的做了另一个方案，SpringSecurity OAuth2 关于 UserAuthenticationConverter就是这个玩意，然后当我和之前的的全局解析方案做对比的时候SpringSecurityOAuth2获取JWT中的数据看到这篇文章中有提到一句我就测试了一下，因为我觉得这个地方都是解析请求头

心得第一次整合项目大致如下！这种是我刚上手刚学会爬的时候写的，写的比较粗糙，而且有一几个很致命的问题：一是没有将资源服和授权服务独立分开，导致了一些问题产生，当然这个问题我也以文章的形式记录下来，SpringSecurityOAuth2登录后无法跳转获取授权码地址，直接跳转根路径原因详解，另一个问题就是那是自学的时候还没有接触到自定义授权模式，只是会使用比较lol的方式采用过滤器认证，然后在认证成功后手动写代码生成Token返回的，这种方式不提倡，那么经过第一个版本的摧残和历练，是的我又不死心大概过了

前言之前写了一大堆关于SpringSecurity OAuth2的相关文章，本以为可以告一段落了，但是有了解到一个新东西，之前没注意到的，就是UserAuthenticationConverter，本章就来看看这是个啥玩意！我们知道授权服可以提供两种格式的Token，一种是默认的字符串，另一种是JWT格式的字符串，关于JWT格式Token我这里就不多逼逼是什么意思勒，我们认证服采用JWT格式主要就是为了提高Token校验的性能，如果我们采用默认的字符串的话默认需要调用认证服进行token检查，就是通过Ht

前言说真的，SpringSecurity OAuth2这套框架会的人真的不多，尤其是比较深入的使用，这也是我聚合这篇文章的初衷！就相对我自己学习这个而言，也花了好多时间，从简单学习SpringSecurity，到分析整个运行流程，再到SpringSecurity OAuth2学习，再到深入源码，授权流程。说实话一路过来确实不容易。真的需要花时间经历，只有这样才能将这套框架变成自己的！聚合1. SpringSecurity OAuth开发前后端分离认证框架介绍...

前言本文是梳理整合SpringCloud和SpringSecurity OAuth2的搭建流程！好久没撸SpringSecurity OAuth2这系列代码了，都快忘了，特写此文章梳理脉络！开干！！！Maven版本微服务版本 <spring-boot.version>2.3.2.RELEASE</spring-boot.version> <spring-cloud.version>Hoxton.SR9</spring-cloud.version&g

前言在我们使用SpringSecurity OAuth2做认证授权时，默认返回都是SpringSecurity OAuth2提供好的，返回不是很友好，本章就是针对这些异常做统一返回处理，主要解决返回格式问题，和返回提示信息重写！我们先来看看SpringSecurity OAuth2默认返回格式，如下！本文将默认返回改造为如下格式{ code：xxx， msg：xxxx， data：xxx}SpringSecurity OAuth2异常处理呢，又分为两部分，一部分为授权服授权时异常，通常包

前言前言也没什么前言了，这个前言只是我的个人习惯，有时候写的出来就写前言，写不出来就编，哈哈哈，玩笑归玩笑，这是继SpringSecurity OAuth2关于AuthorizationCodeServices这篇文章后，又介绍SpringSecurity OAuth2中一个核心组件，大致和AuthorizationCodeServices是差不多的，也是分为授权服内存，JDBC，Redis的，这里我只演示授权服内存、和Redis两种，因为今天有点累了，晚上快下班的时候，感觉到一阵胸痛，身体可能报警去了

前言这是我在梳理另一篇关于SpringSecurity OAuth2完整文章的时候关注到的一个对象，那么下面我们来深入看看这个AuthorizationCodeServices对象！介绍我们知到授权服颁发Token我们可以存储在授权服中，也可以存储在MySQL中，当然也可以存储在Redis中，这个我们是通过TokenStore来实现的，这个我这里就不做重点介绍了，但是授权服中不止给第三方办法Token，当我们在做授权码认证的时候我们还向客户端颁发了一个授权码！那么AuthorizationCodeSe

前言周末闲来无事，谢谢自己的项目，然后想把老的授权模式改造一下，老的是基于SpringSecurity的实现，想升级为SpringSecurity OAuth2模式，于是看了下之前搭建的SpringSecurity OAuth2的框架，代码嫁接进来基本上是没问题的，嫁接进来后满足SpringSecurity OAuth2默认提供的5种授权模式，然后外加一套自定义账号密码登录模式(原有的一套账号密码模式用作Admin管理后台系统登录，这一套自定义的用于客户端的账号密码登录)、验证码登录模式，看了之前写的文章

前言在我们实际开发过程中SpringSecurityOAuth2默认提供的5种授权模式不够用，那么就需要我们自己来定义授权模式，可能有人不是真的很了解SpringSecurityOauth2框架的使用，比如我们要开发一种短信验证码授权登录的场景，可能有些程序员直接就编写一个controller然后自己在controller中组装token，或者是沿用SpringSecurity的过滤器思维，编写一个短信验证么的过滤器，配置在过滤器链上，按照SpringSecurity认证的思维，加上一个登录成功处理器，

这个问题出在AuthenticationManager的配置上，在使用SpringSecurityOAuth2默认的5种授权模式密码模式时需要在@Configuration@EnableWebSecuritypublic class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Bean @Override public AuthenticationManager authenticationManagerBean

在这里插入代码片

自定义用户认证逻辑这篇文章只要是实现web页面登录认证！就是用户通过账号密码登录系统，获得授权！也就是这中样子的登录！实现起来比较简单，别说网页丑，这是SpringSecurity自己默认的登录界面简单实现1.一个登录后访问的请求@RestControllerpublic class TestController { @RequestMapping("/user") public String user(){ return "HelloWorld"; }

记住我功能，这个是登入时常见的功能，就是用户在登入一次以后，勾选记住我功能按钮后，系统会记住用户一段时间，在这段时间内用户不应反复登入系统的操作；简单说明一下：浏览器在用户登入的时候，发送认证请求给UsernamePassworAuthenticationFilter这个身份认证过滤器，或者是自己特定的过滤器，当我们的认证过滤器认证成功后会调用一个RemeberMeService的服务，这个服务里面有一个TokenRepository，这个会生成一个Token，然后将这个Token返回给浏览器并写入到C

前言在学习SpringSecurity这个框架是，做表单登录的时候为了方便测试，一般都会在代码中将用户登录使用的用户名和密码写死，但是在实际开发中肯定是需要连接数据库查询用户信息的，之前写过一篇将用户名密码写死的文章SpringSecurity表单认证，前期学习的时候完全是可以通过写死的这种方式的!补充另一种写死的方式这种写死的方式比上篇文章更加方便，都不需要实现UserDetailsService 接口。 @Autowired public void globalUserDetails(A

springSecurity认证的结果如何在请求间共享那么在多个请求间共享数据小系统就是放在session中的，那么SpringSecurity是什么时候放到session中的，又是什么时候从session中读取出来的看看流程图这里涉及到SecurityContexHolder、SecurityContext、SecurityContextPersistenceFilter这几个类。这里先看看SecurityContexHolder和SecurityContext这两个在认证流程中认证成功调用

这几天由于需求，整合了一下Springsecurity的安全框架，独乐乐不如众乐乐和大家分享一下，避免不必要的坑。## 标题这里奉上GitHub克隆地址点击https://github.com/xjjxltzf/CSDN.git进入正题，本次将采用本人的理解讲解该安全框架的整合。项目结构：一个小domepom.xml导入的依赖&amp;lt;?xml version=&quot;1.0&quot; encod...

在SpringSecurity中身份和权限是分开的，身份也成为角色，其实这里身份和权限标记就是在我们实现的UserDetailsService中设置的@Slf4j@Componentpublic class MyUserDetailsService implements UserDetailsService { @Autowired public PasswordEncoder passwordEncoder() {//密码加密 return new BCryptPas

//获取所以数据 @GetMapping("/returnAll") public Object returnAll(){ return SecurityContextHolder.getContext().getAuthentication(); } //简写 @GetMapping("/simple") public Object simple(Authentication authentication){ return au

FilterChainProxy也是一个Filter,它应用了代理模式和组合模式，它将上面的各个Filter组织到一起在自己内部形成一个filter chain,当自己被调用到时，它其实把任务代理给自己内部的filter chain完成。

概述Spring Security Web使用该Filter解决Cross-Site Request Forgery (CSRF)攻击,使用的模式是Synchronizer token pattern (STP)。STP模式本意是每个请求都生成一个不同的,随机的,不可预测的token用于CSRF保护。这种严格的模式CSRF保护能力很强。但是每请求必验给服务端增加了额外的负担，另外它也要求浏览器必须保持正确的事件顺序，从而会带来一些可用性上的问题(比如用户打开了多个Tab的情况)。所以Spring Se

概述该过滤器会拦截用户请求，看它是否是一个来自用户名/密码表单登录页面提交的用户登录认证请求，缺省使用的匹配模式是:POST /login。缺省情况下，如果是用户登录认证请求，该请求就不会在整个filter chain中继续传递了，而是会被当前过滤器处理并进入响应用户阶段。具体用户登录认证处理逻辑是这样的，它会调用所指定的AuthenticationManager认证所提交的用户名/密码。如果认证成功，则会 ：调用所设置的SessionAuthenticationStrategy会话认证策略;

概述SecurityContextPersistenceFilter有两个主要任务:在请求到达时处理之前，从SecurityContextRepository中获取安全上下文信息填充到SecurityContextHolder;在请求处理结束后返回响应时，将SecurityContextHolder中的安全上下文信息保存回SecurityContextRepository,并清空SecurityContextHolder。通过SecurityContextPersistenceFilter的这种

概述此过滤器用于集成SecurityContext到Spring异步执行机制中的WebAsyncManager。源代码解析package org.springframework.security.web.context.request.async;import java.io.IOException;import java.util.concurrent.Callable;import javax.servlet.FilterChain;import javax.servlet.Servl

概述Spring Securty 使用该Filter在一个请求的处理过程中为响应对象增加一些头部信息。头部信息由外部提供，比如用于增加一些浏览器保护的头部，比如X-Frame-Options, X-XSS-Protection和X-Content-Type-Options等。具体的做法是在请求到达的时候将传入的响应对象包装成一个具有头部写入能力的HeaderWriterResponse对象，HeaderWriterResponse所具备的头部写入能力是这样的 :HeaderWriterRespons

概述在进行安全配置时，不管是明确指定还是使用缺省配置，最终安全配置中都会包含以下退出登录配置信息:怎样的请求是一个退出登录请求这里包含两部分信息: url, http method成功退出登录过程需要做哪些事情也就是各种配置的LogoutHandler核心LogoutHandler:SecurityContextLogoutHandler–销毁session和SecurityContextHolder内容成功退出登录后跳转到哪里也就是配置中的 logoutSuccessUrl

先看看这种核心流程图这张图是SpringSecurity认证涉及到的核心类让应用Debug启动点击表单登录进入到这个就是上图中的绿色过滤器 ， 这个类中首先进入attemptAuthentication这个方法，获取用户名密码，然后用获取到的用户名密码构建了一个UsernamePasswordAuthenticationToken这个对象顶层就是实现了Authentication，这个Authentication实际上就是封装登录这的认证信息，接着上面构建UsernamePasswor

前言在之前文章中有单独写过SpringSecurity表单登录流程源码分析，SpringSocial使用QQ授权登录流程详细分析两篇关于登录流程的，这些其实只是SpringSecurity整个流程的一部分罢了，也就是验证一下用户身份，但是真正的授权还是要这篇文章来讲解的！废话不多说，进入正题吧！这张图是贯穿整个SpringSecurity的核心流程的，但是观看图可能理解是有点抽象，这篇文章就来详细解释这张流程图！理论铺垫SpringSecurity真正判断请求能否通过是在FilterSecurit

一.CSRF是什么？CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。二.CSRF可以做什么？你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。三.CSRF漏洞现状CSRF这种攻击方式在2000年

OAuth协议要解决的问题这里直接举例说明，如我们的微信账号，这个微信号上有我们一些用户信息，如头像昵称，性别等信息！作者我呢要开发一个APP，需要使用微信用户关联微信号登陆，那么就需要得到微信账号授权的用户数据，这里最大的问题是微信肯定不允许我们任意读取用户数据的，那么这里就需要微信用户的授权，授权同意后我使用微信账号的用户数据，当我们的APP有了微信用户的授权后，我们就可以在微信中读取授权用户的微信账户数据了，那么微信就会将用户的账号部分数据开放给我们了，那么我们如何得到用户的授权呢，最传统的做法就是

前言在之前有写过几篇SpringSecurity前后端不分离架构情况下的认证文章，那么随着现在技术的发展用户上网的方式已经不是过去单纯的浏览器，现在很多应用都实现了APP化，还有随着现在互联网技术的发展，传统的前后端不分离的的项目部署方案已经悄然落下帷幕，而现在较为普及的前后端分离的部署方案更受互联网公司的青睐！前后端不分离的相关文章SpringSecurity基本概念入门SpringSecurity表单认证SpringSecurity表单认证源码流程分析SpringSecurity认证的结果

前言在看着篇文章前，首先需要一定的知识储备，SpringCloud这一块我就不多说了，这里着重讲解SpringSecurity OAuth相关的，那么必须具备SpringSecurity和SpringSecurity OAuth相关知识储备，不然一路上会走很多坑！这篇文章是以SpringBoot2.X为基本版本整合的，所以SpringSecurity Oauth的版本也必须与SpringBoot2.X相适配，因为这里就光版本适配就有很多坑，因为SpringSecurity在1.X和2.X的一些默认配置是不

JWT（Json Web Token）是Json开放的一个Token标准，从这个名字来看它是一个令牌（Token）的一个标准。DefaultTokenServices特点：自包含：生成的字符串是包含特定信息的，在做身份权限校验的时候直接解析字符串就能获取当前用户身份权限信息，不需要在存储中在读取校验了密签：可以指定密钥签名，但是不建议将总要数据放入JWT签名串中，因为还是能破解的，这个JWT不是加密，只是签名，防止被篡改，JWT是一套开放的标准，那么别人也能使用这套标准获取用户信息可扩展：可以自

本文将结合SpringSecurityOAuth2采用JWT生成Token的模式自定义JWT数据内容，主要重点是在JWT自定义数据，所以不会过多介绍SpringSecurityOAuth2相关东西，详情请看过往文章1.添加自定义JWT数据模板/** * @author TAO * @description: 给生成的jwt签名中添加自定义数据 * @date 2020/12/12 0:20 */@Slf4jpublic class TokenJwtEnhancer implements To

前言在往期文章中有写过SpringSecurity OAuth使用JWT替换默认Token、SpringSecurityOAuth2采用JWT生成Token的模式自定义JWT数据、这两篇关于JWT的，当然还有一篇是关于JWT拓展数据获取的问题，在SpringSecurity从数据库获取用户信息这篇文章末尾有相关代码，这里用户信息是存放到JWT里面去了，虽然之前这篇文章SpringSecurity OAuth使用JWT替换默认Token中有获取JWT中的自定义数据，但是获取感觉缺点味道！具体获取JWT中自定

最近这段时间一直在潜心研究安全这一块，从单纯的整合SpringSecurity到整合SpringSecurityOAuth，再到SSO单点登陆这几部分简单实用确实不难，但是想要真的搞懂然后在整合到自己的知识体系中来还是需要花一定的时间的！这里有同感的朋友给本文点个赞！这篇文张会先说明登录问题，搭建问题，授权问题，鉴权问题、拦截路由配置，一些特殊的解决方案，以及最近这段时间整个这些东西的一些心得！希望对各位同行有所帮助！开发不易，但不要忘记前行！1.问题铺垫以及产生问题的原因在写SpringSecuri

前言tokenExtractor()这玩意字面意思叫Token提取，确实，这玩意就是干这个的，就是提取Token的，因为我们狭义的认为Token是存放在请求头中的Authorization中的，但是并不只有这一种，共有三种token存放方式，如下！1.在Header中携带Header：Authentication：Bearer xxxxx-xxx-xxx-xxx-xxxxxx2.拼接在url中作为requestParamhttp://localhost:9000/pay/1?access_

前言看过我往期文章的道友应该知道，在20年11月份的时候写过Spring Security和Spring Security OAuth2.0搭建整合一些问题即源码流程分析！但是今天调试框架的时候既然忘了Spring Security OAuth2.0授权链接的源码位置，害，年纪大了脑子不好使了！源码位置/oauth/tokenorg.springframework.security.oauth2.provider.endpoint/oauth/token_keyorg.springframew

前言在学习新框架的时候，先是了解怎么用，在是去了解运行流程、加载流程、然后再试二次开发，本文是针对SpringSecurityOAuth2授权加载流程进行分析源码分析1.加载AuthorizationServerConfig这个类就是标注@EnableAuthorizationServer的配置类，也就是授权服配置类，AuthorizationServerConfig实例化时会进入父类AuthorizationServerConfigurerAdapter进行加载，然后会完Authorizatio