Spring Security OAuth2.0认证授权知识概括

安全框架基本概念
基于Session的认证方式
Spring Security简介
SpringSecurity详解
分布式系统认证方案
OAuth2.0
Spring Cloud Security OAuth2
JWT令牌
Spring Security实现分布式系统授权
SpringSecurity总结

安全框架基本概念

什么是认证：

进入移动互联网时代，大家每天都在刷手机，常用的软件有微信、支付宝、头条等，下边拿微信来举例子说明认证相关的基本概念，在初次使用微信前需要注册成为微信用户，然后输入账号和密码即可登录微信，输入账号和密码登录微信的过程就是认证。
系统为什么要认证？
①认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。
认证：
①用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。
②常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。

什么是会话：

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。会话就是系统为了保持当前用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等。
基于session的认证方式如下图：
①它的交互流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)中，发给客户端的sesssion_id 存放到 cookie 中。
②这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数据，以此完成用户的合法校验，当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
基于token方式如下图：
①它的交互流程是，用户认证成功后，服务端生成一个token发给客户端，客户端可以放到 cookie 或 localStorage等存储中，每次请求时带上 token，服务端收到token通过验证后即可确认用户身份。
总结：
①基于session的认证方式由Servlet规范定制，服务端要存储session信息需要占用内存资源，客户端需要支持cookie；
②基于token的方式则一般不需要服务端存储token，并且不限制客户端的存储方式。如今移动互联网时代更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于token的方式更适合。

什么是授权:

还拿微信来举例子，微信登录成功后用户即可使用微信的功能，比如，发红包、发朋友圈、添加好友等，没有绑定银行卡的用户是无法发送红包的，绑定银行卡的用户才可以发红包，发红包功能、发朋友圈功能都是微信的资源即功能资源，用户拥有发红包功能的权限才可以正常使用发送红包功能，拥有发朋友圈功能的权限才可以使用发朋友圈功能，这个根据用户的权限来控制用户使用资源的过程就是授权。
认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的，控制不同的用户能够访问不同的资源。
授权：授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问。

授权的数据模型:

如何进行授权即如何对用户访问资源进行控制，首先需要学习授权相关的数据模型。
授权可简单理解为Who对What(which)进行How操作，包括如下：
①Who，即主体（Subject），主体一般是指用户，也可以是程序，需要访问系统中的资源。 What，即资源（Resource），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。
②系统菜单、页面、按钮、代码方法都属于系统功能资源，对于web系统每个功能资源通常对应一个URL；系统商品信息、系统订单信息都属于实体资源（数据资源），实体资源由资源类型和资源实例组成，比如商品信息为资源类型，商品编号为001的商品为资源实例。 How，权限/许可（Permission），规定了用户对资源的操作许可，权限离开资源没有意义，如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为001的用户的修改权限等，通过权限可知用户对哪些资源都有哪些操作许可。
③主体、资源、权限关系如下图：

④主体、资源、权限相关的数据模型如下：
<1>主体（用户id、账号、密码、…）
<2>资源（资源id、资源名称、访问地址、…）
<3>权限（权限id、权限标识、权限名称、资源id、…）
<4>角色（角色id、角色名称、…）
<5>角色和权限关系（角色id、权限id、…）
<6>主体（用户）和角色关系（用户id、角色id、…）
⑤主体（用户）、资源、权限关系如下图：

⑥通常企业开发中将资源和权限表合并为一张权限表，如下：
<1>资源（资源id、资源名称、访问地址、…）
<2>权限（权限id、权限标识、权限名称、资源id、…）
⑦合并为：
<1>权限（权限id、权限标识、权限名称、资源名称、资源访问地址、…）
<2>修改后数据模型之间的关系如下图：

RBAC:

如何实现授权？
①业界通常基于RBAC实现授权。
基于角色的访问控制
①RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

②根据上图中的判断逻辑，授权代码可表示如下：
<1>根据下边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

if(主体.hasRole("总经理角色id")){查询工资
}如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断用户的角色是否是总经理或部门经理”，修改代码如下：if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){查询工资
}

基于资源的访问控制
①RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权，比如：用户必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

②优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也不需要修改授权代码，系统可扩展性强。
③根据上图中的判断，授权代码可以表示为：

if(主体.hasPermission("查询工资权限标识")){查询工资
}

总结来说就是基于资源比基于角色拥有更小的粒度，因此更好扩展。

基于Session的认证方式

认证流程：

基于Session认证方式的流程是，用户认证成功后，在服务端生成用户相关的数据保存在session(当前会话)，而发给客户端的sesssion_id 存放到 cookie 中，这样用客户端请求时带上 session_id 就可以验证服务器端是否存在 session数据，以此完成用户的合法校验。当用户退出系统或session过期销毁时,客户端的session_id也就无效了。
下图是session认证方式的流程图：
基于Session的认证机制由Servlet规范定制，Servlet容器已实现，用户通过HttpSession的操作方法即可实现，如下是HttpSession相关的操作API。

方法	含义
HttpSession	getSession(Boolean create) 获取当前HttpSession对象
void	setAttribute(String name,Object value) 向session中存放对象
object	getAttribute(String name) 从session中获取对象
void	removeAttribute(String name); 移除session中对象
void	invalidate() 使HttpSession失效
略	…

Demo要点：
①实现会话功能：首先在UserDto中定义一个SESSION_USER_KEY，作为Session中存放登录用户信息的key。
②授权功能思路：
<1>匿名用户（未登录用户）访问拦截：禁止匿名用户访问某些资源。
<2>登录用户访问拦截：根据用户的权限决定是否能访问某些资源。
③实现授权功能：为了实现这样的功能，我们需要在UserDto里增加权限属性( Set<String>类型)，用于表示该登录用户所拥有的权限。

Spring Security简介

Spring Security介绍：

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。由于它是Spring生态系统中的一员，因此它伴随着整个Spring生态系统不断修正、升级，在spring boot项目中加入spring security更是十分简单，使用Spring Security 减少了为企业系统安全控制编写大量重复代码的工作。
引入以下依赖：在security-springmvc的基础上增加spring-security的依赖：

<dependency><groupId>org.springframework.security</groupId><artifactId>spring‐security‐web</artifactId><version>5.1.4.RELEASE</version>
</dependency>
<dependency><groupId>org.springframework.security</groupId><artifactId>spring‐security‐config</artifactId><version>5.1.4.RELEASE</version>
</dependency>

Spring Security初始化，这里有两种情况：
①如果您不使用 Spring 或 Spring MVC，则需要将WebSecurityConfig传递到超类中，以确保配置被接受。(写一个类然后继承超类进行添加)
②如果我们在应用程序的其他地方使用 Spring，则可能已经有一个WebApplicationInitializer用来加载 Spring 配置。如果我们使用以前的配置，将会得到一个错误。相反，我们应该使用现有的ApplicationContext注册 Spring Security。(在已有的类上进行添加)

--------不使用 Spring 或 Spring MVC--------public class SpringSecurityApplicationInitializerextends AbstractSecurityWebApplicationInitializer { public SpringSecurityApplicationInitializer() {super(WebSecurityConfig.class);     }
}--------使用 Spring--------
public class MvcWebApplicationInitializer extendsAbstractAnnotationConfigDispatcherServletInitializer {@Overrideprotected Class<?>[] getRootConfigClasses() {return new Class[] { WebSecurityConfig.class };}// ... other overrides ...
}

WebSecurityConfig详解：
①WebSecurityConfigurerAdapter在configure(HttpSecurity http)方法中提供了默认配置：
<1>确保对我们应用程序的任何请求都需要对用户进行身份验证
<2>允许用户使用基于表单的登录进行身份验证
<3>允许用户使用 HTTP Basic 身份验证进行身份验证
②使用and()方法表示等效于关闭 XML 标记的 Java 配置，该方法允许我们 continue 配置父级。

@EnableWebSecurity
@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter { }

springSecurity默认提供认证页面(登录，登出)，不需要额外开发。当然我们也可以自定义配置(大部分)：
①使用WebSecurityConfigurerAdapter时，将自动应用登录功能。默认设置是访问 URL/login将通过以下方式登录用户。
②使用WebSecurityConfigurerAdapter时，将自动应用注销功能。默认设置是访问 URL/logout将通过以下方式注销用户。
③除此之外还可以配置登录成功的页面，登录失败的页面以及注销成功的页面。
授权请求：我们可以通过将多个子级添加到http.authorizeRequests()方法中来为 URL 指定自定义要求：
(1) http.authorizeRequests()方法有多个子级，每个匹配器均按声明 Sequences 考虑。
(2) 我们指定了任何用户都可以访问的多个 URL 模式。具体来说，如果 URL 以“/resources /”开头，等于“/signup”或等于“/about”，则任何用户都可以访问请求。
(3) 任何以“/admin /”开头的 URL 都将限于角色为“ ROLE_ADMIN”的用户。您将注意到，由于我们正在调用hasRole方法，因此无需指定“ ROLE_”前缀。
(4) 任何以“/db /”开头的 URL 都要求用户同时具有“ ROLE_ADMIN”和“ ROLE_DBA”。您会注意到，由于我们使用的是hasRole表达式，因此无需指定“ ROLE_”前缀。
(5) antMatchers("/r/r2").hasAuthority(“p2”)表示：访问/r/r2资源的 url需要拥有p2权限。
(6) 尚未匹配的任何 URL 仅要求对用户进行身份验证

protected void configure(HttpSecurity http) throws Exception {http.authorizeRequests()                                                               (1).antMatchers("/resources/**", "/signup", "/about").permitAll()                 (2).antMatchers("/admin/**").hasRole("ADMIN")                                     (3).antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")          (4).antMatchers("/r/r2").hasAuthority("p2")                                         (5).anyRequest().authenticated()                                                  (6).and()// ....formLogin();
}

Authentication认证：
①内存中身份验证：从内存中查
②JDBC 身份验证：从数据库中查
③LDAP 认证：从配置文件中查

   //配置用户信息服务@Beanpublic UserDetailsService userDetailsService()  {InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();manager.createUser(User.withUsername("zhangsan").password("123").authorities("p1").build());manager.createUser(User.withUsername("lisi").password("456").authorities("p2").build());     return manager;}

密码编码：Spring Security 的PasswordEncoder接口用于执行密码的单向转换，以允许安全地存储密码。鉴于PasswordEncoder是一种单向转换，因此在密码转换需要采用两种方式(即存储用于向数据库进行身份验证的凭据)时并不适用。通常，PasswordEncoder用于存储需要与认证时用户提供的密码进行比较的密码。

 //密码加密器@Beanpublic PasswordEncoder passwordEncoder() { return  NoOpPasswordEncoder.getInstance();}

SpringSecurity集成SpringBoot：

Spring Boot是一套Spring的快速开发框架，基于Spring 4.0设计，使用Spring Boot开发可以避免一些繁琐的工程搭建和配置，同时它集成了大量的常用框架，快速导入依赖包，避免依赖包的冲突。Spring Boot提供spring-boot-starter-security用于开发Spring Security应用。
由于Spring boot starter自动装配机制，这里无需使用@EnableWebSecurity，WebSecurityConﬁg内容如下：

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {    //内容跟Spring security入门程序一致
}

SpringSecurity详解

结构总览：

Spring Security所解决的问题就是安全访问控制，而安全访问控制功能其实就是对所有进入系统的请求进行拦截，校验每个请求是否能够访问它所期望的资源。根据前边知识的学习，可以通过Filter或AOP等技术来实现，SpringSecurity对Web资源的保护是靠Filter实现的，所以从这个Filter来入手，逐步深入Spring Security原理。
当初始化Spring Security时，会创建一个名为 SpringSecurityFilterChain的Servlet过滤器，类型为
org.springframework.security.web.FilterChainProxy，它实现了javax.servlet.Filter，因此外部的请求会经过此类，下图是Spring Security过虑器链结构图：
FilterChainProxy是一个代理，真正起作用的是FilterChainProxy中SecurityFilterChain所包含的各个Filter，同时这些Filter作为Bean被Spring管理，它们是Spring Security核心，各有各的职责，但他们并不直接处理用户的认证，也不直接处理用户的授权，而是把它们交给了认证管理器（AuthenticationManager）和决策管理器（AccessDecisionManager）进行处理，下图是FilterChainProxy相关类的UML图示。
spring Security功能的实现主要是由一系列过滤器链相互配合完成。
下面介绍过滤器链中主要的几个过滤器及其作用：
①SecurityContextPersistenceFilter 这个Filter是整个拦截过程的入口和出口（也就是第一个和最后一个拦截器），会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext，然后把它设置给 SecurityContextHolder。在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository，同时清除 securityContextHolder 所持有的 SecurityContext；
②UsernamePasswordAuthenticationFilter 用于处理来自表单提交的认证。该表单必须提供对应的用户名和密码，其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler，这些都可以根据需求做相关改变；
③FilterSecurityInterceptor是用于保护web资源的，使用AccessDecisionManager对当前用户进行授权访问，前面已经详细介绍过了；
④ExceptionTranslationFilter 能够捕获来自 FilterChain 所有的异常，并进行处理。但是它只会处理两类异常： AuthenticationException 和 AccessDeniedException，其它的异常它会继续抛出。

认证流程：

用户提交用户名、密码被SecurityFilterChain中的过滤器获取到，封装为请求Authentication，通常情况下是UsernamePasswordAuthenticationToken这个实现类。
然后过滤器将Authentication提交至认证管理器（AuthenticationManager）进行认证
认证成功后， AuthenticationManager 身份管理器返回一个被填充满了信息的（包括上面提到的权限信息，实例。身份信息，细节信息，但密码通常会被移除）
SecurityContextHolder 安全上下文容器将第3步填充了信息的，通过SecurityContextHolder.getContext().setAuthentication(…)方法，设置到其中。
①可以看出AuthenticationManager接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，它的实现类为ProviderManager。而Spring Security支持多种认证方式，因此ProviderManager维护着一个列表，存放多种认证方式，最终实际的认证工作是由AuthenticationProvider完成的。咱们知道web表单的对应的AuthenticationProvider实现类为 DaoAuthenticationProvider，它的内部又维护着一个UserDetailsService负责UserDetails的获取。最终 AuthenticationProvider将UserDetails填充至Authentication。

AuthenticationProvider(认证流程提供者)：

通过前面的Spring Security认证流程我们得知，认证管理器（AuthenticationManager）委托AuthenticationProvider完成认证工作。
AuthenticationProvider是一个接口，定义如下：

public interface AuthenticationProvider {Authentication authenticate(Authentication authentication)  throws AuthenticationException; boolean supports(Class<?> var1);
}

authenticate()方法定义了认证的实现过程，它的参数是一个Authentication，里面包含了登录用户所提交的用户、密码等。而返回值也是一个Authentication，这个Authentication则是在认证成功后，将用户的权限及其他信息重新组装后生成。
Spring Security中维护着一个列表，存放多种认证方式，不同的认证方式使用不同的AuthenticationProvider。如使用用户名密码登录时，使用AuthenticationProvider1，短信登录时使用AuthenticationProvider2等等这样的例子很多。
每个AuthenticationProvider需要实现supports（）方法来表明自己支持的认证方式，如我们使用表单方式认证，在提交请求时Spring Security会生成UsernamePasswordAuthenticationToken，它是一个Authentication，里面封装着用户提交的用户名、密码信息。而对应的，哪个AuthenticationProvider来处理它？
我们在DaoAuthenticationProvider的基类AbstractUserDetailsAuthenticationProvider发现以下代码：

public boolean supports(Class<?> authentication) {return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);
}

也就是说当web表单提交用户名密码时，Spring Security由DaoAuthenticationProvider处理。
最后，我们来看一下Authentication(认证信息)的结构，它是一个接口，我们之前提到的 UsernamePasswordAuthenticationToken就是它的实现之一：
（1）Authentication是spring security包中的接口，直接继承自Principal类，而Principal是位于包中的。它是表示着一个抽象主体身份，任何主体都有一个名称，因此包含一个getName()方法。
（2）getAuthorities()，权限信息列表，默认是GrantedAuthority接口的一些实现类，通常是代表权限信息的一系列字符串。
（3）getCredentials()，凭证信息，用户输入的密码字符串，在认证过后通常会被移除，用于保障安全。
（4）getDetails()，细节信息，web应用中的实现接口通常为 WebAuthenticationDetails，它记录了访问者的ip地址和sessionId的值。
（5）getPrincipal()，身份信息，大部分情况下返回的是UserDetails接口的实现类，UserDetails代表用户的详细信息，那从Authentication中取出来的UserDetails就是当前登录用户信息，它也是框架中的常用接口之一。

public interface Authentication extends Principal, Serializable {     （1）              Collection<? extends GrantedAuthority> getAuthorities();           （2）Object getCredentials();    （3）Object getDetails();        （4）                                               Object getPrincipal();      （5）  boolean isAuthenticated();                                 void setAuthenticated(boolean var1) throws IllegalArgumentException;
}

UserDetailsService(身份信息)：

现在咱们现在知道DaoAuthenticationProvider处理了web表单的认证逻辑，认证成功后既得到一个Authentication(UsernamePasswordAuthenticationToken实现)，里面包含了身份信息（Principal）。这个身份信息就是一个Object，，大多数情况下它可以被强转为UserDetails对象。
DaoAuthenticationProvider中包含了一个UserDetailsService实例，它负责根据用户名提取用户信息UserDetails(包含密码)，而后DaoAuthenticationProvider会去对比UserDetailsService提取的用户密码与用户提交公开为spring bean来定的密码是否匹配作为认证成功的关键依据，因此可以通过将自定义的UserDetailsService 公开为spring bean来定义自定义身份验证。

public interface UserDetailsService {    UserDetails loadUserByUsername(String username) throws UsernameNotFoundException;
}

很多人把DaoAuthenticationProvider和UserDetailsService的职责搞混淆，其实UserDetailsService只负责从特定的地方（通常是数据库）加载用户信息，仅此而已。而DaoAuthenticationProvider的职责更大，它完成完整的认证流程，同时会把UserDetails填充至Authentication。
上面一直提到UserDetails是用户信息，咱们看一下它的真面目：

public interface UserDetails extends Serializable {Collection<? extends GrantedAuthority> getAuthorities(); String getPassword();String getUsername();boolean isAccountNonExpired();boolean isAccountNonLocked();boolean isCredentialsNonExpired();boolean isEnabled(); }

它和Authentication接口很类似，比如它们都拥有username，authorities。Authentication的getCredentials()与UserDetails中的getPassword()需要被区分对待，前者是用户提交的密码凭证，后者是用户实际存储的密码，认证其实就是对这两者的比对。Authentication中的getAuthorities()实际是由UserDetails的getAuthorities()传递而形成的。还记得Authentication接口中的getDetails()方法吗？其中的UserDetails用户详细信息便是经过了 AuthenticationProvider认证之后被填充的。通过实现UserDetailsService和UserDetails，我们可以完成对用户信息获取方式以及用户信息字段的扩展。
SpringSecurity提供的InMemoryUserDetailsManager(内存认证)，JdbcUserDetailsManager(jdbc认证)就是 UserDetailsService的实现类，主要区别无非就是从内存还是从数据库加载用户。

PasswordEncoder(密码加解密器)：

DaoAuthenticationProvider认证处理器通过UserDetailsService获取到UserDetails后，它是如何与请求Authentication中的密码做对比呢？
在这里Spring Security为了适应多种多样的加密类型，又做了抽象，DaoAuthenticationProvider通过PasswordEncoder接口的matches方法进行密码的对比，而具体的密码对比细节取决于实现：

public interface PasswordEncoder {     String encode(CharSequence var1);boolean matches(CharSequence var1, String var2);default boolean upgradeEncoding(String encodedPassword){return false;}
}

而SpringSecurity提供很多内置的PasswordEncoder，能够开箱即用，使用某种PasswordEncoder只需要进行如下声明即可，如下：

@Bean
public PasswordEncoder passwordEncoder() {     return  NoOpPasswordEncoder.getInstance();
}

NoOpPasswordEncoder采用字符串匹配方法，不对密码进行加密比较处理，密码比较流程如下：
①用户输入密码（明文）
②DaoAuthenticationProvider获取UserDetails（其中存储了用户的正确密码）
③DaoAuthenticationProvider使用PasswordEncoder对输入的密码和正确的密码进行校验，密码一致则校验通过，否则校验失败。NoOpPasswordEncoder的校验规则拿输入的密码和UserDetails中的正确密码进行字符串比较，字符串内容一致则校验通过，否则校验失败。
实际项目中推荐使用BCryptPasswordEncoder, Pbkdf2PasswordEncoder,SCryptPasswordEncoder等，感兴趣的大家可以看看这些PasswordEncoder的具体实现。
Demo：使用BCryptPasswordEncoder：
①配置BCryptPasswordEncoder 在安全配置类中定义：

@Bean
public PasswordEncoder passwordEncoder() {     return new BCryptPasswordEncoder();
}

授权流程：

通过快速上手我们知道，Spring Security可以通过 http.authorizeRequests() 对web请求进行授权保护。Spring Security使用标准Filter建立了对web请求的拦截，最终实现对资源的授权访问。
Spring Security的授权流程如下：
分析授权流程：
①拦截请求，已认证用户访问受保护的web资源将被SecurityFilterChain中的 FilterSecurityInterceptor 的子类拦截。
②获取资源访问策略，FilterSecurityInterceptor会从 SecurityMetadataSource的子类DefaultFilterInvocationSecurityMetadataSource获取要访问当前资源所需要的权限Collection<ConfigAttribute>。
<1>SecurityMetadataSource其实就是读取访问策略的抽象，而读取的内容，其实就是我们配置的访问规则，读取访问策略如下：
③最后，FilterSecurityInterceptor会调用 AccessDecisionManager 进行授权决策，若决策通过，则允许访问资源，否则将禁止访问。

http.authorizeRequests()                                                           .antMatchers("/r/r1").hasAuthority("p1")   .antMatchers("/r/r2").hasAuthority("p2")...

AccessDecisionManager（访问决策管理器）的核心接口如下：
①这里着重说明一下decide的参数：
<1>authentication：要访问资源的访问者的身份
<2>object：要访问的受保护资源，web请求对应FilterInvocation
<3>conﬁgAttributes：是受保护资源的访问策略，通过<4>SecurityMetadataSource获取。
②decide接口就是用来鉴定当前用户是否有访问对应受保护资源的权限。

public interface AccessDecisionManager {     /*** 通过传递的参数来决定用户是否有访问对应受保护资源的权限*/void decide(Authentication authentication,Object object,Collection<ConfigAttribute> configAttributes) throws AccessDeniedException, InsufficientAuthenticationException;//略..
}

授权决策：

AccessDecisionManager采用投票的方式来确定是否能够访问受保护资源。
通过上图可以看出，AccessDecisionManager中包含的一系列AccessDecisionVoter将会被用来对Authentication 是否有权访问受保护对象进行投票，AccessDecisionManager根据投票结果，做出最终决策。AccessDecisionVoter是一个接口，其中定义有三个方法，具体结构如下所示：
①vote()方法的返回结果会是AccessDecisionVoter中定义的三个常量之一。
<1>ACCESS_GRANTED表示同意， ACCESS_DENIED表示拒绝，ACCESS_ABSTAIN表示弃权。
<2>如果一个AccessDecisionVoter不能判定当前 Authentication是否拥有访问对应受保护对象的权限，则其vote()方法的返回值应当为弃权ACCESS_ABSTAIN。

public interface AccessDecisionVoter<S> {int ACCESS_GRANTED = 1;int ACCESS_ABSTAIN = 0;int ACCESS_DENIED = ‐1;boolean supports(ConfigAttribute var1);     boolean supports(Class<?> var1);int vote(Authentication var1, S var2, Collection<ConfigAttribute> var3); }

Spring Security内置了三个基于投票的AccessDecisionManager实现类如下，它们分别是AﬃrmativeBased、ConsensusBased和UnanimousBased。
AﬃrmativeBased的逻辑是：
①只要有AccessDecisionVoter的投票为ACCESS_GRANTED则同意用户进行访问；
②如果全部弃权也表示通过；
③如果没有一个人投赞成票，但是有人投反对票，则将抛出AccessDeniedException。 Spring security默认使用的是AﬃrmativeBased。
ConsensusBased的逻辑是：
①如果赞成票多于反对票则表示通过。
②反过来，如果反对票多于赞成票则将抛出AccessDeniedException。
③如果赞成票与反对票相同且不等于0，并且属性allowIfEqualGrantedDeniedDecisions的值为true，则表示通过，否则将抛出异常AccessDeniedException。参数allowIfEqualGrantedDeniedDecisions的值默认为true。
④如果所有的AccessDecisionVoter都弃权了，则将视参数allowIfAllAbstainDecisions的值而定，如果该值为true则表示通过，否则将抛出异常AccessDeniedException。参数allowIfAllAbstainDecisions的值默认为false。
UnanimousBased的逻辑与另外两种实现有点不一样，另外两种会一次性把受保护对象的配置属性全部传递给AccessDecisionVoter进行投票，而UnanimousBased会一次只传递一个ConﬁgAttribute给AccessDecisionVoter进行投票。这也就意味着如果我们的AccessDecisionVoter的逻辑是只要传递进来的ConﬁgAttribute中有一个能够匹配则投赞成票，但是放到UnanimousBased中其投票结果就不一定是赞成了。UnanimousBased的逻辑具体来说是这样的：
①如果受保护对象配置的某一个ConﬁgAttribute被任意的AccessDecisionVoter反对了，则将抛出 AccessDeniedException。
②如果没有反对票，但是有赞成票，则表示通过。
③如果全部弃权了，则将视参数allowIfAllAbstainDecisions的值而定，true则通过，false则抛出 AccessDeniedException。
④Spring Security也内置一些投票者实现类如RoleVoter、AuthenticatedVoter和WebExpressionVoter等，可以自行查阅资料进行学习。

自定义认证：

Spring Security提供了非常好的认证扩展方法，比如：快速上手中将用户信息存储到内存中，实际开发中用户信息通常在数据库，Spring security可以实现从数据库读取用户信息，Spring security还支持多种授权方法。
自定义登录页面：在快速上手中，你可能会想知道登录页面从哪里来的？因为我们并没有提供任何的HTML或JSP文件。Spring Security的默认配置没有明确设定一个登录页面的URL，因此Spring Security会根据启用的功能自动生成一个登录页面URL，并使用默认URL处理登录的提交内容，登录后跳转的到默认URL等等。尽管自动生成的登录页面很方便快速启动和运行，但大多数应用程序都希望定义自己的登录页面。
问题解决：spring security为防止CSRF（Cross-site request forgery跨站请求伪造）的发生，限制了除了get以外的大多数方法。
解决方法一：屏蔽CSRF控制，即spring security不再限制CSRF。配置WebSecurityConﬁg

@Override
protected void configure(HttpSecurity http) throws Exception { //屏蔽CSRF控制，即spring security不再限制CSRF http.csrf().disable()  ...
}

解决方法二：在login.jsp页面添加一个token，spring security会验证token，如果token合法则可以继续请求。修改login.jsp

<form action="login" method="post">
<input type="hidden"  name="${_csrf.parameterName}"   value="${_csrf.token}"/>
...
</form>

会话:

用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保存在会话中。spring security提供会话管理，认证通过后将身份信息放入SecurityContextHolder上下文，SecurityContext与当前线程进行绑定，方便获取用户身份。

会话控制:

我们可以通过以下选项准确控制会话何时创建以及Spring Security如何与之交互：

机制	描述
always	如果没有session存在就创建一个
ifRequired	如果需要就创建一个Session（默认）登录时
never	SpringSecurity 将不会创建Session，但是如果应用中其他地方创建了Session，那么Spring Security将会使用它。
stateless	SpringSecurity将绝对不会创建Session，也不使用Session

通过以下配置方式对该选项进行配置：

@Override
protected void configure(HttpSecurity http) throws Exception {http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED) }

默认情况下，Spring Security会为每个登录成功的用户会新建一个Session，就是ifRequired 。若选用never，则指示Spring Security对登录成功的用户不创建Session了，但若你的应用程序在某地方新建了session，那么Spring Security会用它的。若使用stateless，则说明SpringSecurity对登录成功的用户不会创建Session了，你的应用程序也不会允许新建session。并且它会暗示不使用cookie，所以每个请求都需要重新进行身份验证。这种无状态架构适用于REST API
及其无状态认证机制。

会话超时：

可以再sevlet容器中设置Session的超时时间，如下设置Session有效期为3600s； spring boot 配置文件：

server.servlet.session.timeout=3600s

session超时之后，可以通过Spring Security 设置跳转的路径。

http.sessionManagement().expiredUrl("/login‐view?error=EXPIRED_SESSION").invalidSessionUrl("/login‐view?error=INVALID_SESSION");

expired指session过期，invalidSession指传入的sessionid无效。

安全会话cookie：

我们可以使用httpOnly和secure标签来保护我们的会话cookie：
①httpOnly：如果为true，那么浏览器脚本将无法访问cookie ②secure：如果为true，则cookie将仅通过HTTPS连接发送
spring boot 配置文件：

server.servlet.session.cookie.http‐only=true
server.servlet.session.cookie.secure=true

退出：

Spring security默认实现了logout退出，访问/logout，果然不出所料，退出功能Spring也替我们做好了。
①点击“Log Out”退出成功。
②退出后访问其它url判断是否成功退出。
这里也可以自定义退出成功的页面：在WebSecurityConﬁg的protected void conﬁgure(HttpSecurity http)中配置：

.and()
.logout()
.logoutUrl("/logout")
.logoutSuccessUrl("/login‐view?logout");

当退出操作出发时，将发生：
①使HTTP Session 无效清除 SecurityContextHolder
②跳转到/login-view?logout
③但是，类似于配置登录功能，咱们可以进一步自定义退出功能：
（1）提供系统退出支持，使用WebSecurityConfigurerAdapter会自动被应用。
（2）设置触发退出操作的URL (默认是/logout)。
（3）退出之后跳转的URL。默认是/login?logout。
（4）定制的 LogoutSuccessHandler ，用于实现用户退出成功时的处理。如果指定了这个选项那么 logoutSuccessUrl() 的设置会被忽略。，用于实现用户退出时的清理工作.默认 SecurityContextLogoutHandler 会被添加
（5）添加一个LogoutHandler，用于实现用户退出时的清理工作.默认SecurityContextLogoutHandler会被添加为最后一个LogoutHandler。
（6）指定是否在退出时让HttpSession无效。默认设置为 true。

@Override
protected void configure(HttpSecurity http) throws Exception {http.authorizeRequests()//....and()(1)    .logout()                                                    (2)    .logoutUrl("/logout")                                    (3)    .logoutSuccessUrl("/login‐view?logout")             (4)    .logoutSuccessHandler(logoutSuccessHandler)            (5)    .addLogoutHandler(logoutHandler) (6)    .invalidateHttpSession(true);
}

注意：如果让logout在GET请求下生效，必须关闭防止CSRF攻击csrf().disable()。如果开启了CSRF，必须使用post方式请求/logout
logoutHandler：一般来说，LogoutHandler的实现类被用来执行必要的清理，因而他们不应该抛出异常。
下面是Spring Security提供的一些实现：
①PersistentTokenBasedRememberMeServices 基于持久化token的RememberMe功能的相关清理
②TokenBasedRememberMeService 基于token的RememberMe功能的相关清理
③CookieClearingLogoutHandler 退出时Cookie的相关清理
④CsrfLogoutHandler 负责在退出时移除csrfToken ⑤SecurityContextLogoutHandler 退出时SecurityContext的相关清理
链式API提供了调用相应的LogoutHandler实现的快捷方式，比如deleteCookies()。

授权：

授权的方式包括 web授权和方法授权，web授权是通过 url拦截进行授权，方法授权是通过方法拦截进行授权。他们都会调用accessDecisionManager进行授权决策，若为web授权则拦截器为FilterSecurityInterceptor；若为方法授权则拦截器为MethodSecurityInterceptor。如果同时通过web授权和方法授权则先执行web授权，再执行方法授权，最后决策通过，则允许访问资源，否则将禁止访问。
类关系如下：
注意：
①规则的顺序是重要的,更具体的规则应该先写.现在以/ admin开始的所有内容都需要具有ADMIN角色的身份验证用户,即使是/ admin / login路径(因为/ admin / login已经被/ admin / **规则匹配,因此第二个规则被忽略).因此,登录页面的规则应该在/ admin / **规则之前。
②保护URL常用的方法有：
<1>authenticated() 保护URL，需要用户登录
<2>permitAll() 指定URL无需保护，一般应用与静态资源文件
<3>hasRole(String role) 限制单个角色访问，角色将被增加 “ROLE_” .所以”ADMIN” 将和 “ROLE_ADMIN”进行比较.
<4>hasAuthority(String authority) 限制单个权限访问
<5>hasAnyRole(String… roles)允许多个角色访问.
<6>hasAnyAuthority(String… authorities) 允许多个权限访问.
<7>access(String attribute) 该方法使用 SpEL表达式, 所以可以创建复杂的限制。链接：Spring Security–基于表达式的访问控制 access的使用
<8>hasIpAddress(String ipaddressExpression) 限制IP地址或子网

方法授权：

现在我们已经掌握了使用如何使用 http.authorizeRequests() 对web资源进行授权保护，从Spring Security2.0版本开始，它支持服务层方法的安全性的支持。本节学@PreAuthorize,@PostAuthorize,@Secured三类注解。
我们可以在任何 @Configuration 实例上使用 @EnableGlobalMethodSecurity 注释来启用基于注解的安全性。以下内容将启用Spring Security的@Secured 注释。

@EnableGlobalMethodSecurity(securedEnabled = true)
public class MethodSecurityConfig {// ...}

然后向方法（在类或接口上）添加注解就会限制对该方法的访问。 Spring Security的原生注释支持为该方法定义了一组属性。这些将被传递给AccessDecisionManager以供它作出实际的决定：

public interface BankService {@Secured("IS_AUTHENTICATED_ANONYMOUSLY") public Account readAccount(Long id);@Secured("IS_AUTHENTICATED_ANONYMOUSLY") public Account[] findAccounts();@Secured("ROLE_TELLER")public Account post(Account account, double amount);
}

以上配置标明readAccount、ﬁndAccounts方法可匿名访问，底层使用WebExpressionVoter投票器，可从AﬃrmativeBased第23行代码跟踪。post方法需要有TELLER角色才能访问，底层使用RoleVoter投票器。
使用如下代码可启用prePost注解的支持

@EnableGlobalMethodSecurity(prePostEnabled = true)
public class MethodSecurityConfig {
// ...
}

相应Java代码如下：

public interface BankService {@PreAuthorize("isAnonymous()") public Account readAccount(Long id);@PreAuthorize("isAnonymous()") public Account[] findAccounts();@PreAuthorize("hasAuthority('p_transfer') and hasAuthority('p_read_account')") public Account post(Account account, double amount);
}

以上配置标明readAccount、ﬁndAccounts方法可匿名访问，post方法需要同时拥有p_transfer和p_read_account
权限才能访问，底层使用WebExpressionVoter投票器，可从AﬃrmativeBased第23行代码跟踪。

HttpFirewall：

在 Spring Security 中提供了一个 HttpFirewall，看名字就知道这是一个请求防火墙，它可以自动处理掉一些非法请求。HttpFirewall 目前一共有两个实现类：一个是严格模式的防火墙设置，还有一个默认防火墙设置。
①DefaultHttpFirewall 的限制相对于 StrictHttpFirewall 要宽松一些，当然也意味着安全性不如 StrictHttpFirewall。
②Spring Security 中默认使用的是 StrictHttpFirewall。
链接：springsecurity登录功能拦截_Spring Security 自带防火墙！你都不知道自己的系统有多安全

分布式系统认证方案

什么是分布式系统：

随着软件环境和需求的变化，软件的架构由单体结构演变为分布式架构，具有分布式架构的系统叫分布式系统，分布式系统的运行通常依赖网络，它将单体结构的系统分为若干服务，服务之间通过网络交互来完成用户的业务处理，当前流行的微服务架构就是分布式系统架构，如下图：
分布式系统具体如下基本特点：
①分布性：每个部分都可以独立部署，服务之间交互通过网络进行通信，比如：订单服务、商品服务。
②伸缩性：每个部分都可以集群方式部署，并可针对部分结点进行硬件及软件扩容，具有一定的伸缩能力。
③共享性：每个部分都可以作为共享资源对外提供服务，多个部分可能有操作共享资源的情况。
④开放性：每个部分根据需求都可以对外发布共享资源的访问接口，并可允许第三方系统访问。

分布式认证需求：

分布式系统的每个服务都会有认证、授权的需求，如果每个服务都实现一套认证授权逻辑会非常冗余，考虑分布式系统共享性的特点，需要由独立的认证服务处理系统认证授权的请求；考虑分布式系统开放性的特点，不仅对系统内部服务提供认证，对第三方系统也要提供认证。分布式认证的需求总结如下。
统一认证授权：
①提供独立的认证服务，统一处理认证授权。
②无论是不同类型的用户，还是不同种类的客户端(web端，H5、APP)，均采用一致的认证、权限、会话机制，实现统一认证授权。
③要实现统一则认证方式必须可扩展，支持各种认证需求，比如：用户名密码认证、短信验证码、二维码、人脸识别等认证方式，并可以非常灵活的切换。
应用接入认证：
①应提供扩展和开放能力，提供安全的系统对接机制，并可开放部分API给接入第三方使用，一方应用（内部系统服务）和三方应用（第三方应用）均采用统一机制接入。

分布式认证方案：

基于session的认证方式
①在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。
②这个时候，通常的做法有下面几种：
<1>Session复制：多台应用服务器之间同步session，使session保持一致，对外透明。
<2>Session黏贴：当用户访问集群中某台服务器后，强制指定后续所有请求均落到此机器上。
<3>Session集中存储：将Session存入分布式缓存中，所有服务器应用实例统一从分布式缓存中存取Session。
③总体来讲，基于session认证的认证方式，可以更好的在服务端对会话进行控制，且安全性较高。但是，session机制方式基于cookie，在复杂多样的移动客户端上不能有效的使用，并且无法跨域，另外随着系统的扩展需提高 session的复制、黏贴及存储的容错性。

基于token的认证方式
①基于token的认证方式，服务端不用存储认证数据，易维护扩展性强，客户端可以把token 存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

技术方案：

根据选型的分析，决定采用基于token的认证方式，它的优点是：
①适合统一认证的机制，客户端、一方应用、三方应用都遵循一致的认证机制。
②token认证方式对第三方应用接入更适合，因为它更开放，可使用当前有流行的开放协议Oauth2.0、JWT等。
③一般情况服务端无需存储会话信息，减轻了服务端的压力。
分布式系统认证技术方案见下图：
流程描述：
①用户通过接入方（应用）登录，接入方采取OAuth2.0方式在统一认证服务(UAA)中认证。
②认证服务(UAA)调用验证该用户的身份是否合法，并获取用户权限信息。
③认证服务(UAA)获取接入方权限信息，并验证接入方是否合法。
④若登录用户以及接入方都合法，认证服务生成jwt令牌返回给接入方，其中jwt中包含了用户权限及接入方权限。
⑤后续，接入方携带jwt令牌对API网关内的微服务资源进行访问。⑥API网关对令牌解析、并验证接入方的权限是否能够访问本次请求的微服务。
⑦如果接入方的权限没问题，API网关将原请求header中附加解析后的明文Token，并将请求转发至微服务。
⑧微服务收到请求，明文token中包含登录用户的身份和权限信息。因此后续微服务自己可以干两件事：1，用户授权拦截（看当前用户是否有权访问该资源）2，将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）
流程所涉及到UAA服务、API网关这三个组件职责如下：
①统一认证服务(UAA)：它承载了OAuth2.0接入方认证、登入用户的认证、授权以及生成令牌的职责，完成实际的用户认证、授权功能。
②API网关：作为系统的唯一入口，API网关为接入方提供定制的API集合，它可能还具有其它职责，如身份验证、监控、负载均衡、缓存等。API网关方式的核心要点是，所有的接入方和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。

OAuth2.0

OAuth2.0介绍：

OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth1.0即完全废止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。
Oauth协议目前发展到2.0版本，1.0版本过于复杂，2.0版本已得到广泛应用。
链接：
①参考
②Oauth协议
下边分析一个Oauth2认证的例子，通过例子去理解OAuth2.0协议的认证流程，本例子是黑马程序员网站使用微信认证的过程，这个过程的简要描述如下：
①用户借助微信认证登录黑马程序员网站，用户就不用单独在黑马程序员注册用户，怎么样算认证成功吗？黑马程序员网站需要成功从微信获取用户的身份信息则认为用户认证成功，那如何从微信获取用户的身份信息？用户信息的拥有者是用户本人，微信需要经过用户的同意方可为黑马程序员网站生成令牌，黑马程序员网站拿此令牌方可从微信获取用户的信息。
<1>客户端请求第三方授权：
1、用户进入黑马程序的登录页面，点击微信的图标以微信账号登录系统，用户是自己在微信里信息的资源拥有者。

2、点击“微信”出现一个二维码，此时用户扫描二维码，开始给黑马程序员授权。

<2>资源拥有者同意给客户端授权：
1、资源拥有者扫描二维码表示资源拥有者同意给客户端授权，微信会对资源拥有者的身份进行验证，验证通过后，微信会询问用户是否给授权黑马程序员访问自己的微信数据，用户点击“确认登录”表示同意授权，微信认证服务器会颁发一个授权码，并重定向到黑马程序员的网站。

<3>客户端获取到授权码，请求认证服务器申请令牌：
1、此过程用户看不到，客户端应用程序请求认证服务器，请求携带授权码。
<4>认证服务器向客户端响应令牌：
1、微信认证服务器验证了客户端请求的授权码，如果合法则给客户端颁发令牌，令牌是客户端访问资源的通行证。此交互过程用户看不到，当客户端拿到令牌后，用户在黑马程序员看到已经登录成功。
<5>客户端请求资源服务器的资源：
1、客户端携带令牌访问资源服务器的资源。
2、黑马程序员网站携带令牌请求访问微信服务器获取用户的基本信息。
<6>资源服务器返回受保护资源：
1、资源服务器校验令牌的合法性，如果合法则向用户响应资源信息内容。
以上认证授权详细的执行流程如下：
OAauth2.0包括以下角色：
①客户端：本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。
②资源拥有者：通常为用户，也可以是应用程序，即该资源的拥有者。
③授权服务器（也称认证服务器）：用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌（access_token），作为客户端访问资源服务器的凭据。本例为微信的认证服务器。
④资源服务器：存储资源的服务器，本例子为微信存储的用户信息。
现在还有一个问题：
①服务提供商能允许随便一个客户端就接入到它的授权服务器吗？答案是否定的，服务提供商会给准入的接入方一个身份，用于接入时的凭据：
<1> client_id：客户端标识
<2> client_secret：客户端秘钥
②因此准确来说，授权服务器对两种OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端。

Spring Cloud Security OAuth2

环境介绍：

Spring-Security-OAuth2是对OAuth2的一种实现，并且跟我们之前学习的SpringSecurity相辅相成，与SpringCloud体系的集成也非常便利，接下来，我们需要对它进行学习，最终使用它来实现我们设计的分布式认证授权解决方案。
OAuth2.0的服务提供方涵盖两个服务，即授权服务 (Authorization Server，也叫认证服务) 和资源服务(Resource Server)，使用 Spring Security OAuth2的时候你可以选择把它们在同一个应用程序中实现，也可以选择建立使用同一个授权服务的多个资源服务。
授权服务 (Authorization Server）应包含对接入端以及登入用户的合法性进行验证并颁发token等功能，对令牌的请求端点由 Spring MVC 控制器进行实现，下面是配置一个认证服务必须要实现的endpoints：
①AuthorizationEndpoint服务于认证请求。默认 URL：/oauth/authorize。
②TokenEndpoint服务于访问令牌的请求。默认 URL：/oauth/token。
<1>资源服务 (Resource Server)，应包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等，下面的过滤器用于实现 OAuth 2.0 资源服务：
③OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。
本教程分别创建uaa授权服务（也可叫认证服务）和order订单资源服务。
①认证流程如下：
<1>客户端请求UAA授权服务进行认证。
<2>认证通过后由UAA颁发令牌。
<3>客户端携带令牌Token请求资源服务。
<4>资源服务校验令牌的合法性，合法即返回资源信息。

环境搭建：

创建UAA授权服务工程：

-----本工程采用SpringBoot开发，每个工程编写一个启动类：------
@SpringBootApplication
@EnableDiscoveryClient
@EnableHystrix
@EnableFeignClients(basePackages =
{"com.itheima.security.distributed.uaa"})
public class UAAServer { public static void main(String[] args) { SpringApplication.run(UAAServer.class, args);    }
} ---------配置文件在resources下创建application.properties----
spring.application.name=uaa‐service
server.port=53020
spring.main.allow‐bean‐definition‐overriding = true
logging.level.root = debug
logging.level.org.springframework.web = info
spring.http.encoding.enabled = true
spring.http.encoding.charset = UTF‐8
spring.http.encoding.force = true
server.tomcat.remote_ip_header = x‐forwarded‐for
server.tomcat.protocol_header = x‐forwarded‐proto
server.use‐forward‐headers = true
server.servlet.context‐path = /uaa
spring.freemarker.enabled = true
spring.freemarker.suffix = .html
spring.freemarker.request‐context‐attribute = rc
spring.freemarker.content‐type = text/html
spring.freemarker.charset = UTF‐8
spring.mvc.throw‐exception‐if‐no‐handler‐found = true
spring.resources.add‐mappings = false
spring.datasource.url = jdbc:mysql://localhost:3306/user_db?useUnicode=true
spring.datasource.username = root
spring.datasource.password = mysql
spring.datasource.driver‐class‐name = com.mysql.jdbc.Driver
#eureka.client.serviceUrl.defaultZone = http://localhost:53000/eureka/ #eureka.instance.preferIpAddress = true
#eureka.instance.instance‐id = ${spring.application.name}:${spring.cloud.client.ip‐ address}:${spring.application.instance_id:${server.port}}
management.endpoints.web.exposure.include = refresh,health,info,env
feign.hystrix.enabled = true
feign.compression.request.enabled = true
feign.compression.request.mime‐types[0] = text/xml
feign.compression.request.mime‐types[1] = application/xml
feign.compression.request.mime‐types[2] = application/json
feign.compression.request.min‐request‐size = 2048
feign.compression.response.enabled = true

创建Order资源服务工程：
①本工程为Order订单服务工程，访问本工程的资源需要认证通过。
②本工程的目的主要是测试认证授权的功能，所以不涉及订单管理相关业务。

---------在resources中创建application.properties----------
spring.application.name=order‐service
server.port=53021
spring.main.allow‐bean‐definition‐overriding = true logging.level.root = debug
logging.level.org.springframework.web = info
spring.http.encoding.enabled = true
spring.http.encoding.charset = UTF‐8
spring.http.encoding.force = true
server.tomcat.remote_ip_header = x‐forwarded‐for
server.tomcat.protocol_header = x‐forwarded‐proto
server.use‐forward‐headers = true
server.servlet.context‐path = /order
spring.freemarker.enabled = true
spring.freemarker.suffix = .html
spring.freemarker.request‐context‐attribute = rc
spring.freemarker.content‐type = text/html
spring.freemarker.charset = UTF‐8
spring.mvc.throw‐exception‐if‐no‐handler‐found = true
spring.resources.add‐mappings = false
#eureka.client.serviceUrl.defaultZone = http://localhost:53000/eureka/ #eureka.instance.preferIpAddress = true
#eureka.instance.instance‐id = ${spring.application.name}:${spring.cloud.client.ip‐ address}:${spring.application.instance_id:${server.port}}
management.endpoints.web.exposure.include = refresh,health,info,env
feign.hystrix.enabled = true
feign.compression.request.enabled = true
feign.compression.request.mime‐types[0] = text/xml
feign.compression.request.mime‐types[1] = application/xml
feign.compression.request.mime‐types[2] = application/json
feign.compression.request.min‐request‐size = 2048
feign.compression.response.enabled = true

授权服务器配置：

EnableAuthorizationServer：可以用@EnableAuthorizationServer 注解并继承AuthorizationServerConﬁgurerAdapter来配置OAuth2.0 授权服务器。
在Conﬁg包下创建AuthorizationServer：

@Configuration
@EnableAuthorizationServer
public class AuthorizationServer extendsAuthorizationServerConfigurerAdapter {         //略...}

AuthorizationServerConﬁgurerAdapter要求配置以下几个类，这几个类是由Spring创建的独立的配置对象，它们会被Spring传入AuthorizationServerConﬁgurer中进行配置：
①ClientDetailsServiceConﬁgurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。
②AuthorizationServerEndpointsConﬁgurer：用来配置令牌（token）的访问端点和令牌服务(token
services)。
③AuthorizationServerSecurityConﬁgurer：用来配置令牌端点的安全约束.

public class AuthorizationServerConfigurerAdapter implements AuthorizationServerConfigurer {public AuthorizationServerConfigurerAdapter() {}public void configure(AuthorizationServerSecurityConfigurer security) throws Exception {}public void configure(ClientDetailsServiceConfigurer clients) throws Exception {}public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {}
}

配置客户端详细信息：

ClientDetailsServiceConﬁgurer能够使用内存或者JDBC来实现客户端详情服务（ClientDetailsService），ClientDetailsService负责查找ClientDetails，而ClientDetails有几个重要的属性如下列表：
①clientId：（必须的）用来标识客户的Id。
②secret：（需要值得信任的客户端）客户端安全码，如果有的话。
③scope：用来限制客户端的访问范围，如果为空（默认）的话，那么客户端拥有全部的访问范围。 ④authorizedGrantTypes：此客户端可以使用的授权类型，默认为空。
⑤authorities：此客户端可以使用的权限（基于Spring Security authorities）。
客户端详情（Client Details）能够在应用程序运行的时候进行更新，可以通过访问底层的存储服务（例如将客户端详情存储在一个关系数据库的表中，就可以使用 JdbcClientDetailsService）或者通过自己实现ClientRegistrationService接口（同时你也可以实现 ClientDetailsService 接口）来进行管理。
我们暂时使用内存方式存储客户端详情信息，配置如下:

 @Overridepublic void configure(ClientDetailsServiceConfigurer clients) throws Exception {//     clients.withClientDetails(clientDetailsService);         clients.inMemory()// 使用in‐memory存储.withClient("c1")// client_id.secret(new BCryptPasswordEncoder().encode("secret")) .resourceIds("res1").authorizedGrantTypes("authorization_code",
"password","client_credentials","implicit","refresh_token")
// 该client允许的授权类型 authorization_code,password,refresh_token,implicit,client_credentials.scopes("all")// 允许的授权范围                 .autoApprove(false)//加上验证回调地址.redirectUris("http://www.baidu.com"); }

管理令牌：

AuthorizationServerTokenServices 接口定义了一些操作使得你可以对令牌进行一些必要的管理，令牌可以被用来加载身份信息，里面包含了这个令牌的相关权限。
自己可以创建 AuthorizationServerTokenServices 这个接口的实现，则需要继承 DefaultTokenServices 这个类，里面包含了一些有用实现，你可以使用它来修改令牌的格式和令牌的存储。默认的，当它尝试创建一个令牌的时候，是使用随机值来进行填充的，除了持久化令牌是委托一个 TokenStore 接口来实现以外，这个类几乎帮你做了所有的事情。并且 TokenStore 这个接口有一个默认的实现，它就是 InMemoryTokenStore ，如其命名，所有的令牌是被保存在了内存中。除了使用这个类以外，你还可以使用一些其他的预定义实现，下面有几个版本，它们都实现了TokenStore接口：
①InMemoryTokenStore：这个版本的实现是被默认采用的，它可以完美的工作在单服务器上（即访问并发量压力不大的情况下，并且它在失败的时候不会进行备份），大多数的项目都可以使用这个版本的实现来进行尝试，你可以在开发的时候使用它来进行管理，因为不会被保存到磁盘中，所以更易于调试。
②JdbcTokenStore：这是一个基于JDBC的实现版本，令牌会被保存进关系型数据库。使用这个版本的实现时，你可以在不同的服务器之间共享令牌信息，使用这个版本的时候请注意把"spring-jdbc"这个依赖加入到你的 classpath当中。
③JwtTokenStore：这个版本的全称是 JSON Web Token（JWT），它可以把令牌相关的数据进行编码（因此对于后端服务来说，它不需要进行存储，这将是一个重大优势），但是它有一个缺点，那就是撤销一个已经授权令牌将会非常困难，所以它通常用来处理一个生命周期较短的令牌以及撤销刷新令牌（refresh_token）。另外一个缺点就是这个令牌占用的空间会比较大，如果你加入了比较多用户凭证信息。JwtTokenStore 不会保存任何数据，但是它在转换令牌值以及授权信息方面与 DefaultTokenServices 所扮演的角色是一样的。
定义TokenConﬁg：在conﬁg包下定义TokenConﬁg，我们暂时先使用InMemoryTokenStore，生成一个普通的令牌。

@Configuration
public class TokenConfig {     @Bean public TokenStore tokenStore() { return new InMemoryTokenStore();     }
}

定义AuthorizationServerTokenServices：在AuthorizationServer中定义AuthorizationServerTokenServices

 @Autowired private TokenStore tokenStore; @Autowired private ClientDetailsService clientDetailsService; @Bean public AuthorizationServerTokenServices tokenService() {       DefaultTokenServices service=new DefaultTokenServices(); service.setClientDetailsService(clientDetailsService); service.setSupportRefreshToken(true); service.setTokenStore(tokenStore); service.setAccessTokenValiditySeconds(7200); // 令牌默认有效期2小时 service.setRefreshTokenValiditySeconds(259200); // 刷新令牌默认有效期3天  return service; }

令牌访问端点配置：

AuthorizationServerEndpointsConﬁgurer 这个对象的实例可以完成令牌服务以及令牌endpoint配置。
配置授权类型（Grant Types）：AuthorizationServerEndpointsConﬁgurer 通过设定以下属性决定支持的授权类型（Grant Types）：
①authenticationManager：认证管理器，当你选择了资源所有者密码（password）授权类型的时候，请设置这个属性注入一个 AuthenticationManager 对象。
②userDetailsService：如果你设置了这个属性的话，那说明你有一个自己的 UserDetailsService 接口的实现，或者你可以把这个东西设置到全局域上面去（例如 GlobalAuthenticationManagerConﬁgurer 这个配置对象），当你设置了这个之后，那么 “refresh_token” 即刷新令牌授权类型模式的流程中就会包含一个检查，用来确保这个账号是否仍然有效，假如说你禁用了这个账户的话。
③authorizationCodeServices：这个属性是用来设置授权码服务的（即 AuthorizationCodeServices 的实例对象），主要用于 “authorization_code” 授权码类型模式。
④implicitGrantService：这个属性用于设置隐式授权模式，用来管理隐式授权模式的状态。
⑤tokenGranter：当你设置了这个东西（即 TokenGranter 接口实现），那么授权将会交由你来完全掌控，并且会忽略掉上面的这几个属性，这个属性一般是用作拓展用途的，即标准的四种授权模式已经满足不了你的需求的时候，才会考虑使用这个。
配置授权端点的URL（Endpoint URLs）：
①AuthorizationServerEndpointsConﬁgurer 这个配置对象有一个叫做 pathMapping() 的方法用来配置端点URL链接，它有两个参数：
<1>第一个参数：String 类型的，这个端点URL的默认链接。
<2>第二个参数：String 类型的，你要进行替代的URL链接。
②以上的参数都将以 “/” 字符为开始的字符串，框架的默认URL链接如下列表，可以作为这个 pathMapping() 方法的第一个参数：
<1>/oauth/authorize：授权端点。 /oauth/token：令牌端点。
<2>/oauth/conﬁrm_access：用户确认授权提交端点。 /oauth/error：授权服务错误信息端点。
<3>/oauth/check_token：用于资源服务访问的令牌解析端点。
<4>/oauth/token_key：提供公有密匙的端点，如果你使用JWT令牌的话。
③需要注意的是授权端点这个URL应该被Spring Security保护起来只供授权用户访问. 在④AuthorizationServer配置令牌访问端点：

 @Autowired private AuthorizationCodeServices authorizationCodeServices; @Autowired private AuthenticationManager authenticationManager; @Override public void configure(AuthorizationServerEndpointsConfigurer endpoints) {endpoints .authenticationManager(authenticationManager) .authorizationCodeServices(authorizationCodeServices)             .tokenServices(tokenService()) .allowedTokenEndpointRequestMethods(HttpMethod.POST);    } @Bean public AuthorizationCodeServices authorizationCodeServices() { //设置授权码模式的授权码如何 存取，暂时采用内存方式 return new InMemoryAuthorizationCodeServices(); }

令牌端点的安全约束：

AuthorizationServerSecurityConﬁgurer：用来配置令牌端点(Token Endpoint)的安全约束，在
AuthorizationServer中配置如下：
（1）tokenkey这个endpoint当使用JwtToken且使用非对称加密时，资源服务用于获取公钥而开放的，这里指这个 endpoint完全公开。
（2）checkToken这个endpoint完全公开
（3）允许表单认证

@Override
public void configure(AuthorizationServerSecurityConfigurer security){    security.tokenKeyAccess("permitAll()")       (1).checkTokenAccess("permitAll()")     (2)                                                        .allowFormAuthenticationForClients()  (3)                                                            ;
}

授权服务配置总结：

授权服务配置分成三大块，可以关联记忆。
既然要完成认证，它首先得知道客户端信息从哪儿读取，因此要进行客户端详情配置。
既然要颁发token，那必须得定义token的相关endpoint，以及token如何存取，以及客户端支持哪些类型的 token。
既然暴露除了一些endpoint，那对这些endpoint可以定义一些安全上的约束等。

web安全配置：

将Spring-Boot工程中的WebSecurityConﬁg拷贝到UAA工程中。

@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true,prePostEnabled = true)
public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Bean public PasswordEncoder passwordEncoder() {         return new BCryptPasswordEncoder();     } @Bean public AuthenticationManager authenticationManagerBean() throws Exception {return super.authenticationManagerBean(); } //安全拦截机制（最重要）     @Override protected void configure(HttpSecurity http) throws Exception {    http.csrf().disable() .authorizeRequests() .antMatchers("/r/r1").hasAnyAuthority("p1")  .antMatchers("/login*").permitAll() .anyRequest().authenticated() .and() .formLogin(); }
}

授权码模式：

授权码模式流程图：
（1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息。如：
①参数列表如下：
<1>client_id：客户端准入标识。
<2>response_type：授权码模式固定为code。 scope：客户端权限。
<3>redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。

/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com

（2）浏览器出现向授权服务器授权页面，之后将用户同意授权。
（3）授权服务器将授权码（AuthorizationCode）转经浏览器发送给client(通过redirect_uri)。
（4）客户端拿着授权码向授权服务器索要访问access_token，请求如下：
①参数列表如下
<1>client_id：客户端准入标识。 client_secret：客户端秘钥。
<2>grant_type：授权类型，填写authorization_code，表示授权码模式
<3>code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请。 <4>redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致。

/uaa/oauth/token?
client_id=c1&client_secret=secret&grant_type=authorization_code&code=5PgfcD&redirect_uri=http://w ww.baidu.com

（5）授权服务器返回令牌(access_token)：这种模式是四种模式中最安全的一种模式。一般用于client是Web服务器端应用或第三方的原生App调用资源服务的时候。因为在这种模式中access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减小了令牌泄漏的风险。

授权码模式测试：

浏览器访问认证页面：

http://localhost:53020/uaa/oauth/authorize?
client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com

然后输入模拟的账号和密码点登陆之后进入授权页面：
确认授权后，浏览器会重定向到指定路径（oauth_client_details表中的web_server_redirect_uri）并附加验证码?code=DB2mFj（每次不一样），最后使用该验证码获取token。

POST http://localhost:53020/uaa/oauth/token

授权码简化模式：

简化模式交互图：
（1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息。如：
①参数描述同授权码模式，注意response_type=token，说明是简化模式。

/uaa/oauth/authorize?client_id=c1&response_type=token&scope=all&redirect_uri=http://www.baidu.com

（2）浏览器出现向授权服务器授权页面，之后将用户同意授权。
（3）授权服务器将授权码将令牌（access_token）以Hash的形式存放在重定向uri的fargment中发送给浏览器。
注：fragment 主要是用来标识 URI 所标识资源里的某个资源，在 URI 的末尾通过（#）作为 fragment 的开头，其中# 不属于 fragment 的值。如https://domain/index#L18这个 URI 中 L18 就是 fragment 的值。大家只需要知道js通过响应浏览器地址栏变化的方式能获取到fragment 就行了。
一般来说，简化模式用于没有服务器端的第三方单页面应用，因为没有服务器端就无法接收授权码。

授权码简化模式测试：

浏览器访问认证页面：

http://localhost:53020/uaa/oauth/authorize?
client_id=c1&response_type=token&scope=all&redirect_uri=http://www.baidu.com

然后输入模拟的账号和密码点登陆之后进入授权页面：
确认授权后，浏览器会重定向到指定路径（oauth_client_details表中的web_server_redirect_uri）并以Hash的形式存放在重定向uri的fargment中,如：

http://aa.bb.cc/receive#access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZW5hbn...

密码模式：

流程图：
（1）资源拥有者将用户名、密码发送给客户端
（2）客户端拿着资源拥有者的用户名、密码向授权服务器请求令牌（access_token），请求如下：
①参数列表如下：
<1>client_id：客户端准入标识。
<2> client_secret：客户端秘钥。
<3>grant_type：授权类型，填写password表示密码模式
<4>username：资源拥有者用户名。
<5>password：资源拥有者密码。

/uaa/oauth/token?
client_id=c1&client_secret=secret&grant_type=password&username=shangsan&password=123

（3）授权服务器将令牌（access_token）发送给client：这种模式十分简单，但是却意味着直接将用户敏感信息泄漏给了client，因此这就说明这种模式只能用于client是我们自己开发的情况下。因此密码模式一般用于我们自己开发的，第一方原生App或第一方单页面应用。

密码模式测试：

POST http://localhost:53020/uaa/oauth/token

请求参数：
返回结果：

客户端模式：

流程图：
（1）客户端向授权服务器发送自己的身份信息，并请求令牌（access_token）
（2）确认客户端身份无误后，将令牌（access_token）发送给client，请求如下：
①参数列表如下：
<1>client_id：客户端准入标识。
<2>client_secret：客户端秘钥。
<3>grant_type：授权类型，填写client_credentials表示客户端模式：这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。因此这种模式一般用来提供给我们完全信任的服务器端服务。比如，合作方系统对接，拉取一组用户信息。

/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=client_credentials

客户端模式测试：

POST http://localhost:53020/uaa/oauth/token

请求参数：
返回结果：

资源服务案例：

资源服务器配置：@EnableResourceServer 注解到一个 @Conﬁguration 配置类上，并且必须使用 ResourceServerConﬁgurer 这个配置对象来进行配置（可以选择继承自 ResourceServerConﬁgurerAdapter 然后覆写其中的方法，参数就是这个对象的实例），下面是一些可以配置的属性：
①ResourceServerSecurityConﬁgurer中主要包括：
<1>tokenServices：ResourceServerTokenServices 类的实例，用来实现令牌服务。
<2>tokenStore：TokenStore类的实例，指定令牌如何访问，与tokenServices配置可选
<3>resourceId：这个资源服务的ID，这个属性是可选的，但是推荐设置并在授权服务中进行验证。
<4>其他的拓展属性例如 tokenExtractor 令牌提取器用来提取请求中的令牌。
HttpSecurity配置这个与Spring Security类似：
①请求匹配器，用来设置需要进行保护的资源路径，默认的情况下是保护资源服务的全部路径。
②通过http.authorizeRequests()来设置受保护资源的访问规则
③其他的自定义权限保护规则通过 HttpSecurity 来进行配置。
@EnableResourceServer 注解自动增加了一个类型为OAuth2AuthenticationProcessingFilter的过滤器链
编写ResouceServerConﬁg：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import
org.springframework.security.config.annotation.method.configuration.EnableGlobalMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.http.SessionCreationPolicy;
import
org.springframework.security.oauth2.config.annotation.web.configuration.EnableResourceServer; import
org.springframework.security.oauth2.config.annotation.web.configuration.ResourceServerConfigurerA dapter;
import
org.springframework.security.oauth2.config.annotation.web.configurers.ResourceServerSecurityConfi gurer;
import org.springframework.security.oauth2.provider.token.RemoteTokenServices;
import org.springframework.security.oauth2.provider.token.ResourceServerTokenServices; @Configuration
@EnableResourceServer
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class ResouceServerConfig extends ResourceServerConfigurerAdapter {public static final String RESOURCE_ID = "res1";@Override public void configure(ResourceServerSecurityConfigurer resources) {resources.resourceId(RESOURCE_ID) .tokenServices(tokenService())                 .stateless(true); } @Override public void configure(HttpSecurity http) throws Exception {         http .authorizeRequests() .antMatchers("/**").access("#oauth2.hasScope('all')")                 .and().csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);       }
}

验证token：ResourceServerTokenServices 是组成授权服务的另一半，如果你的授权服务和资源服务在同一个应用程序上的话，你可以使用 DefaultTokenServices ，这样的话，你就不用考虑关于实现所有必要的接口的一致性问题。如果你的资源服务器是分离开的，那么你就必须要确保能够有匹配授权服务提供的 ResourceServerTokenServices，它知道如何对令牌进行解码。
令牌解析方法：使用DefaultTokenServices 在资源服务器本地配置令牌存储、解码、解析方式使用 RemoteTokenServices 资源服务器通过 HTTP 请求来解码令牌，每次都请求授权服务器端点 /oauth/check_token
使用授权服务的 /oauth/check_token 端点你需要在授权服务将这个端点暴露出去，以便资源服务可以进行访问，这在咱们授权服务配置中已经提到了，下面是一个例子,在这个例子中，我们在授权服务中配置了 /oauth/check_token 和 /oauth/token_key 这两个端点：

@Override
public void configure(AuthorizationServerSecurityConfigurer security) throws Exception {security.tokenKeyAccess("permitAll()")// /oauth/token_key 安全配置.checkTokenAccess("permitAll()") // /oauth/check_token 安全配置
}

在资源服务配置RemoteTokenServices ，在ResouceServerConﬁg中配置：

//资源服务令牌解析服务 @Bean
public ResourceServerTokenServices tokenService() { //使用远程服务请求授权服务器校验token,必须指定校验token 的url、client_id，client_secret     RemoteTokenServices service=new RemoteTokenServices(); service.setCheckTokenEndpointUrl("http://localhost:53020/uaa/oauth/check_token"); service.setClientId("c1"); service.setClientSecret("secret");     return service;
}
@Override
public void configure(ResourceServerSecurityConfigurer resources) { resources.resourceId(RESOURCE_ID) .tokenServices(tokenService()) .stateless(true);
}

编写资源：在controller包下编写OrderController，此controller表示订单资源的访问类：

@RestController
public class OrderController {     @GetMapping(value = "/r1") @PreAuthorize("hasAnyAuthority('p1')")     public String r1(){ return "访问资源1";     }
}

添加安全访问控制：

@Configuration
@EnableGlobalMethodSecurity(securedEnabled = true,prePostEnabled = true)
public class WebSecurityConfig extends WebSecurityConfigurerAdapter { //安全拦截机制（最重要）     @Override protected void configure(HttpSecurity http) throws Exception {http.csrf().disable() .authorizeRequests()
//          .antMatchers("/r/r1").hasAuthority("p2")
//          .antMatchers("/r/r2").hasAuthority("p2") .antMatchers("/r/**").authenticated()//所有/r/**的请求必须认证通过  .anyRequest().permitAll()//除了/r/**，其它的请求可以访问 ;     }
}

资源服务测试：

申请令牌：这里我们使用密码方式

响应结果： { "access_token": "e3360db3‐2d85‐41c9‐ac5e‐b9adba48e26c",     "token_type": "bearer", "expires_in": 7199,     "scope": "all"
}

请求资源：按照oauth2.0协议要求，请求资源需要携带token，如下： token的参数名称为：Authorization，值为：Bearer token值
如果token错误，则授权失败，如下：

{ "error": "invalid_token", "error_description": "f3360db3‐2d85‐41c9‐ac5e‐b9adba48e26c"
}

JWT令牌

JWT介绍：

通过上边的测试我们发现，当资源服务和授权服务不在一起时资源服务使用RemoteTokenServices 远程请求授权服务验证token，如果访问量较大将会影响系统的性能。
解决上边问题：令牌采用JWT格式即可解决上边的问题，用户认证通过会得到一个JWT令牌，JWT令牌中已经包括了用户相关的信息，客户端只需要携带JWT访问资源服务，资源服务根据事先约定的算法自行完成令牌校验，无需每次都请求认证服务完成授权。
什么是JWT？JSON Web Token（JWT）是一个开放的行业标准（RFC 7519），它定义了一种简介的、自包含的协议格式，用于在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任。JWT可以使用HMAC算法或使用RSA的公钥/私钥对来签名，防止被篡改。
JWT令牌的优点：
1）jwt基于json，非常方便解析。
2）可以在令牌中自定义丰富的内容，易扩展。
3）通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。
4）资源服务使用JWT可不依赖认证服务即可完成授权。
缺点：
１）JWT令牌较长，占存储空间比较大。

JWT令牌结构：

通过学习JWT令牌结构为自定义jwt令牌打好基础。JWT令牌由三部分组成，每部分中间使用点（.）分隔，比如：xxxxx.yyyyy.zzzzz
Header：头部包括令牌的类型（即JWT）及使用的哈希算法（如HMAC SHA256或RSA）一个例子如下：下边是Header部分的内容，将上边的内容使用Base64Url编码，得到一个字符串就是JWT令牌的第一部分。

{ "alg": "HS256",   "typ": "JWT"
}

Payload：第二部分是负载，内容也是一个json对象，它是存放有效信息的地方，它可以存放jwt提供的现成字段，比如：iss（签发者）,exp（过期时间戳）, sub（面向的用户）等，也可自定义字段。
此部分不建议存放敏感信息，因为此部分可以解码还原原始内容。最后将第二部分负载使用Base64Url编码，得到一个字符串就是JWT令牌的第二部分。一个例子：

{ "sub": "1234567890",   "name": "456", "admin": true
}

Signature：第三部分是签名，此部分用于防止jwt内容被篡改。这个部分使用base64url将前两部分进行编码，编码后使用点（.）连接组成字符串，最后使用header中声明签名算法进行签名。一个例子：
①base64UrlEncode(header)：jwt令牌的第一部分。
②base64UrlEncode(payload)：jwt令牌的第二部分。
③secret：签名所使用的密钥。

HMACSHA256( base64UrlEncode(header) + "." +   base64UrlEncode(payload), secret)

配置JWT令牌服务：

在uaa中配置jwt令牌服务，即可实现生成jwt格式的令牌。
1、TokenConﬁg

@Configuration
public class TokenConfig { private String SIGNING_KEY = "uaa123";     @Bean public TokenStore tokenStore() { return new JwtTokenStore(accessTokenConverter());     } @Bean public JwtAccessTokenConverter accessTokenConverter() { JwtAccessTokenConverter converter = new JwtAccessTokenConverter(); converter.setSigningKey(SIGNING_KEY); //对称秘钥，资源服务器使用该秘钥来验证return converter; }
}

2、定义JWT令牌服务

@Autowired
private JwtAccessTokenConverter accessTokenConverter;  @Bean
public AuthorizationServerTokenServices tokenService() { DefaultTokenServices service=new DefaultTokenServices(); service.setClientDetailsService(clientDetailsService); service.setSupportRefreshToken(true); service.setTokenStore(tokenStore); TokenEnhancerChain tokenEnhancerChain = new TokenEnhancerChain(); tokenEnhancerChain.setTokenEnhancers(Arrays.asList(accessTokenConverter)); service.setTokenEnhancer(tokenEnhancerChain); service.setAccessTokenValiditySeconds(7200); // 令牌默认有效期2小时 service.setRefreshTokenValiditySeconds(259200); // 刷新令牌默认有效期3天       return service; }

生成jwt令牌：

响应：

校验jwt令牌：

资源服务需要和授权服务拥有一致的签字、令牌服务等：
1、将授权服务中的TokenConﬁg类拷贝到资源服务中
2、屏蔽资源服务原来的令牌服务类

@Configuration
@EnableResourceServer
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class ResouceServerConfig extends ResourceServerConfigurerAdapter { public static final String RESOURCE_ID = "res1";     @Autowired TokenStore tokenStore;     //资源服务令牌解析服务
//    @Bean
//    public ResourceServerTokenServices tokenService() {
//        //使用远程服务请求授权服务器校验token,必须指定校验token 的url、client_id，client_secret
//        RemoteTokenServices service=new RemoteTokenServices();
//        service.setCheckTokenEndpointUrl("http://localhost:53020/uaa/oauth/check_token"); //        service.setClientId("c1");
//        service.setClientSecret("secret"); //        return service;
//    } @Override public void configure(ResourceServerSecurityConfigurer resources) {resources.resourceId(RESOURCE_ID) .tokenStore(tokenStore)                 .stateless(true); }

3、测试
1）申请jwt令牌
2）使用令牌请求资源
小技巧：令牌申请成功可以使用/uaa/oauth/check_token校验令牌的有效性，并查询令牌的内容，例子如下：

完善环境配置：

截止目前客户端信息和授权码仍然存储在内存中，生产环境中通过会存储在数据库中，下边完善环境的配置：
①在user_db中创建如下表：
②oauth_code表，Spring Security OAuth2使用，用来存储授权码
配置授权服务：
（1）修改AuthorizationServer：ClientDetailsService和AuthorizationCodeServices从数据库读取数据。

@Configuration
@EnableAuthorizationServer
public class AuthorizationServer extends AuthorizationServerConfigurerAdapter {@Autowiredprivate TokenStore tokenStore; @Autowiredprivate JwtAccessTokenConverter accessTokenConverter; @Autowiredprivate ClientDetailsService clientDetailsService; @Autowiredprivate AuthorizationCodeServices authorizationCodeServices; @Autowiredprivate AuthenticationManager authenticationManager; /*** 1.客户端详情相关配置  */@Beanpublic PasswordEncoder passwordEncoder() {         return new BCryptPasswordEncoder();     }@Beanpublic ClientDetailsService clientDetailsService(DataSource dataSource) {ClientDetailsService clientDetailsService = new JdbcClientDetailsService(dataSource); ((JdbcClientDetailsService) clientDetailsService).setPasswordEncoder(passwordEncoder());return clientDetailsService; }@Overridepublic void configure(ClientDetailsServiceConfigurer clients) throws Exception {clients.withClientDetails(clientDetailsService); }/*** 2.配置令牌服务(token services)  */@Beanpublic AuthorizationServerTokenServices tokenService() { DefaultTokenServices service=new DefaultTokenServices();service.setClientDetailsService(clientDetailsService);service.setSupportRefreshToken(true);//支持刷新令牌service.setTokenStore(tokenStore); //绑定tokenStoreTokenEnhancerChain tokenEnhancerChain = new TokenEnhancerChain();tokenEnhancerChain.setTokenEnhancers(Arrays.asList(accessTokenConverter));service.setTokenEnhancer(tokenEnhancerChain);service.setAccessTokenValiditySeconds(7200); // 令牌默认有效期2小时service.setRefreshTokenValiditySeconds(259200); // 刷新令牌默认有效期3天 return service;}/*** 3.配置令牌（token）的访问端点  */@Beanpublic AuthorizationCodeServices authorizationCodeServices(DataSource dataSource) {return new JdbcAuthorizationCodeServices(dataSource);//设置授权码模式的授权码如何存取}@Overridepublic void configure(AuthorizationServerEndpointsConfigurer endpoints) {endpoints.authenticationManager(authenticationManager).authorizationCodeServices(authorizationCodeServices) .tokenServices(tokenService())              .allowedTokenEndpointRequestMethods(HttpMethod.POST);
}/*** 4.配置令牌端点(Token Endpoint)的安全约束  */@Overridepublic void configure(AuthorizationServerSecurityConfigurer security){ security.tokenKeyAccess("permitAll()") .checkTokenAccess("permitAll()").allowFormAuthenticationForClients()//允许表单认证;}
}

测试：
1、测试申请令牌：使用密码模式申请令牌，客户端信息需要和数据库中的信息一致。
2、测试授权码模式：生成的授权存储到数据库中。

Spring Security实现分布式系统授权

回顾技术方案如下：

1、UAA认证服务负责认证授权。
2、所有请求经过网关到达微服务
3、网关负责鉴权客户端以及请求转发
4、网关将token解析后传给微服务，微服务进行授权。

注册中心：

所有微服务的请求都经过网关，网关从注册中心读取微服务的地址，将请求转发至微服务。本节完成注册中心的搭建，注册中心采用Eureka。
配置文件：在resources中配置application.yml

spring: application: name: distributed‐discovery
server: port: 53000 #启动端口 eureka: server: enable‐self‐preservation: false    #关闭服务器自我保护，客户端心跳检测15分钟内错误达到80%服务会保 护，导致别人还认为是好用的服务 eviction‐interval‐timer‐in‐ms: 10000 #清理间隔（单位毫秒，默认是60*1000）5秒将客户端剔除的服务在服 务注册列表中剔除#  shouldUseReadOnlyResponseCache: true #eureka是CAP理论种基于AP策略，为了保证强一致性关闭此切换CP 默认不关闭 false关闭 client:  register‐with‐eureka: false  #false:不作为一个客户端注册到注册中心 fetch‐registry: false      #为true时，可以启动，但报异常：Cannot execute request on any known server instance‐info‐replication‐interval‐seconds: 10      serviceUrl:  defaultZone: http://localhost:${server.port}/eureka/   instance: hostname: ${spring.cloud.client.ip‐address}     prefer‐ip‐address: true instance‐id: ${spring.application.name}:${spring.cloud.client.ip‐ address}:${spring.application.instance_id:${server.port}}

启动类：

package com.itheima.security.distributed.discovery;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
@SpringBootApplication @EnableEurekaServer
public class DiscoveryServer { public static void main(String[] args) { SpringApplication.run(DiscoveryServer.class, args);}
}

网关：

网关整合 OAuth2.0 有两种思路，一种是认证服务器生成jwt令牌, 所有请求统一在网关层验证，判断权限等操作；另一种是由各资源服务处理，网关只做请求转发。
我们选用第一种。我们把API网关作为OAuth2.0的资源服务器角色，实现接入客户端权限拦截、令牌解析并转发当前登录用户信息(jsonToken)给微服务，这样下游微服务就不需要关心令牌格式解析以及OAuth2.0相关机制了。
API网关在认证授权体系里主要负责两件事：
（1）作为OAuth2.0的资源服务器角色，实现接入方权限拦截。
（2）令牌解析并转发当前登录用户信息（明文token）给微服务
微服务拿到明文token(明文token中包含登录用户的身份和权限信息)后也需要做两件事：
（1）用户授权拦截（看当前用户是否有权访问该资源）
（2）将用户信息存储进当前线程上下文（有利于后续业务逻辑随时获取当前用户信息）
配置文件：配置application.properties

spring.application.name=gateway‐server server.port=53010
spring.main.allow‐bean‐definition‐overriding = true logging.level.root = info
logging.level.org.springframework = info
zuul.retryable = true
zuul.ignoredServices = *
zuul.add‐host‐header = true
zuul.sensitiveHeaders = *
zuul.routes.uaa‐service.stripPrefix = false
zuul.routes.uaa‐service.path = /uaa/**
zuul.routes.order‐service.stripPrefix = false
zuul.routes.order‐service.path = /order/**
eureka.client.serviceUrl.defaultZone = http://localhost:53000/eureka/
eureka.instance.preferIpAddress = true
eureka.instance.instance‐id = ${spring.application.name}:${spring.cloud.client.ip‐ address}:${spring.application.instance_id:${server.port}}
management.endpoints.web.exposure.include = refresh,health,info,env
feign.hystrix.enabled = true
feign.compression.request.enabled = true
feign.compression.request.mime‐types[0] = text/xml
feign.compression.request.mime‐types[1] = application/xml
feign.compression.request.mime‐types[2] = application/json
feign.compression.request.min‐request‐size = 2048
feign.compression.response.enabled = true

统一认证服务（UAA）与统一用户服务都是网关下微服务，需要在网关上新增路由配置：

zuul.routes.uaa‐service.stripPrefix = false
zuul.routes.uaa‐service.path = /uaa/**
zuul.routes.user‐service.stripPrefix = false
zuul.routes.user‐service.path = /order/**

上面配置了网关接收的请求url若符合/order/**表达式，将被被转发至order-service(统一用户服务)。
启动类：

@SpringBootApplication
@EnableZuulProxy
@EnableDiscoveryClient
public class GatewayServer { public static void main(String[] args) { SpringApplication.run(GatewayServer.class, args);     }
}

token配置：

前面也介绍了，资源服务器由于需要验证并解析令牌，往往可以通过在授权服务器暴露check_token的Endpoint来完成，而我们在授权服务器使用的是对称加密的jwt，因此知道密钥即可，资源服务与授权服务本就是对称设计，那我们把授权服务的TokenConﬁg两个类拷贝过来就行。

package com.itheima.security.distributed.gateway.config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.oauth2.provider.token.TokenStore;
import org.springframework.security.oauth2.provider.token.store.JwtAccessTokenConverter;
import org.springframework.security.oauth2.provider.token.store.JwtTokenStore;
@Configuration
public class TokenConfig { private String SIGNING_KEY = "uaa123";     @Bean public TokenStore tokenStore() {return new JwtTokenStore(accessTokenConverter());     } @Bean public JwtAccessTokenConverter accessTokenConverter() { JwtAccessTokenConverter converter = new JwtAccessTokenConverter(); converter.setSigningKey(SIGNING_KEY); //对称秘钥，资源服务器使用该秘钥来解密return converter; }
}

配置资源服务：

在ResouceServerConﬁg中定义资源服务配置，主要配置的内容就是定义一些匹配规则，描述某个接入客户端需要什么样的权限才能访问某个微服务，如：

@Configuration
public class ResouceServerConfig {public static final String RESOURCE_ID = "res1";     /*** 统一认证服务(UAA) 资源拦截      */@Configuration@EnableResourceServerpublic class UAAServerConfig extends ResourceServerConfigurerAdapter {@Autowiredprivate TokenStore tokenStore;         @Overridepublic void configure(ResourceServerSecurityConfigurer resources){resources.tokenStore(tokenStore).resourceId(RESOURCE_ID).stateless(true);         }@Overridepublic void configure(HttpSecurity http) throws Exception {http.authorizeRequests().antMatchers("/uaa/**").permitAll();         }}/***  订单服务      */@Configuration@EnableResourceServerpublic class OrderServerConfig extends ResourceServerConfigurerAdapter {@Autowiredprivate TokenStore tokenStore;         @Overridepublic void configure(ResourceServerSecurityConfigurer resources) {resources.tokenStore(tokenStore).resourceId(RESOURCE_ID).stateless(true);         }@Overridepublic void configure(HttpSecurity http) throws Exception {             http.authorizeRequests().antMatchers("/order/**").access("#oauth2.hasScope('ROLE_API')");   }}
}

上面定义了两个微服务的资源，其中：
①UAAServerConﬁg指定了若请求匹配/uaa/**网关不进行拦截。
②OrderServerConﬁg指定了若请求匹配/order/**，也就是访问统一用户服务，接入客户端需要有scope中包含 read，并且authorities(权限)中需要包含ROLE_USER。
③由于res1这个接入客户端，read包括ROLE_ADMIN,ROLE_USER,ROLE_API三个权限。

安全配置：

@Configuration
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {     @Override protected void configure(HttpSecurity http) throws Exception {         http .authorizeRequests() .antMatchers("/**").permitAll()                 .and().csrf().disable(); }
}

转发明文token给微服务：

通过Zuul过滤器的方式实现，目的是让下游微服务能够很方便的获取到当前的登录用户信息（明文token）
（1）实现Zuul前置过滤器，完成当前登录用户信息提取，并放入转发微服务的request中

/*** token传递拦截  */
public class AuthFilter extends ZuulFilter {     @Overridepublic boolean shouldFilter() {         return true;}@Overridepublic String filterType() {         return "pre";}@Overridepublic int filterOrder() {         return 0;}@Overridepublic Object run() {         /*** 1.获取令牌内容          */RequestContext ctx = RequestContext.getCurrentContext();Authentication authentication = SecurityContextHolder.getContext().getAuthentication();         if(!(authentication instanceof OAuth2Authentication)){ // 无token访问网关内资源的情况，目 前仅有uua服务直接暴露return null;         }OAuth2Authentication oauth2Authentication  = (OAuth2Authentication)authentication;         Authentication userAuthentication = oauth2Authentication.getUserAuthentication();         Object principal = userAuthentication.getPrincipal();/*** 2.组装明文token，转发给微服务，放入header，名称为json‐token          */List<String> authorities = new ArrayList();userAuthentication.getAuthorities().stream().forEach(s ‐ >authorities.add(((GrantedAuthority) s).getAuthority()));OAuth2Request oAuth2Request = oauth2Authentication.getOAuth2Request();Map<String, String> requestParameters = oAuth2Request.getRequestParameters();         Map<String,Object> jsonToken = new HashMap<>(requestParameters);if(userAuthentication != null){jsonToken.put("principal",userAuthentication.getName());             jsonToken.put("authorities",authorities);}ctx.addZuulRequestHeader("json‐token",
EncryptUtil.encodeUTF8StringBase64(JSON.toJSONString(jsonToken)));         return null;} }

（2）将ﬁlter纳入spring 容器：配置AuthFilter

package com.itheima.security.distributed.gateway.config;
import com.itheima.security.distributed.gateway.filter.AuthFilter;
import org.springframework.boot.web.servlet.FilterRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.Ordered;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;
@Configuration
public class ZuulConfig {     @Beanpublic AuthFilter preFileter() {         return new AuthFilter();}@Beanpublic FilterRegistrationBean corsFilter() {final UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();         final CorsConfiguration config = new CorsConfiguration();config.setAllowCredentials(true);config.addAllowedOrigin("*");config.addAllowedHeader("*");config.addAllowedMethod("*");config.setMaxAge(18000L);source.registerCorsConfiguration("/**", config);         CorsFilter corsFilter = new CorsFilter(source);FilterRegistrationBean bean = new FilterRegistrationBean(corsFilter);         bean.setOrder(Ordered.HIGHEST_PRECEDENCE);return bean;     }
}

微服务用户鉴权拦截：

当微服务收到明文token时，应该怎么鉴权拦截呢？自己实现一个ﬁlter？自己解析明文token，自己定义一套资源访问策略？
能不能适配Spring Security呢，是不是突然想起了前面我们实现的Spring Security基于token认证例子。咱们还拿统一用户服务作为网关下游微服务，对它进行改造，增加微服务用户鉴权拦截功能。
（1）增加测试资源 OrderController增加以下endpoint

 @PreAuthorize("hasAuthority('p1')")     @GetMapping(value = "/r1")public String r1(){UserDTO user = (UserDTO)
SecurityContextHolder.getContext().getAuthentication().getPrincipal();          return user.getUsername() + "访问资源1";}@PreAuthorize("hasAuthority('p2')")     @GetMapping(value = "/r2")public String r2(){//通过Spring Security API获取当前登录用户         UserDTO user = (UserDTO)SecurityContextHolder.getContext().getAuthentication().getPrincipal();         return user.getUsername() + "访问资源2";}

（2）Spring Security配置：开启方法保护，并增加Spring配置策略，除了/login方法不受保护(统一认证要调用)，其他资源全部需要认证才能访问。综合上面的配置，咱们共定义了三个资源了，拥有p1权限可以访问r1资源，拥有p2权限可以访问r2资源，只要认证通过就能访问r3资源。

 @Overridepublic void configure(HttpSecurity http) throws Exception {         http.authorizeRequests().antMatchers("/**").access("#oauth2.hasScope('ROLE_ADMIN')") .and().csrf().disable().sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);}

（3）定义ﬁlter拦截token，并形成Spring Security的Authentication对象

@Component
public class TokenAuthenticationFilter extends OncePerRequestFilter {     @Overrideprotected void doFilterInternal(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, FilterChain filterChain) throws ServletException, IOException {String token = httpServletRequest.getHeader("json‐token");         if (token != null){//1.解析tokenString json = EncryptUtil.decodeUTF8StringBase64(token);             JSONObject userJson = JSON.parseObject(json);UserDTO user = new UserDTO();user.setUsername(userJson.getString("principal"));JSONArray authoritiesArray = userJson.getJSONArray("authorities");String  [] authorities = authoritiesArray.toArray( new
String[authoritiesArray.size()]);//2.新建并填充authenticationUsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(user, null, AuthorityUtils.createAuthorityList(authorities));authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(                     httpServletRequest));//3.将authentication保存进安全上下文SecurityContextHolder.getContext().setAuthentication(authentication);         }filterChain.doFilter(httpServletRequest, httpServletResponse);     }
}

经过上边的过虑器，资源服务中就可以方便到的获取用户的身份信息：

UserDTO user = (UserDTO) SecurityContextHolder.getContext().getAuthentication().getPrincipal();

还是三个步骤：
1.解析token
2.新建并填充authentication
3.将authentication保存进安全上下文
4.剩下的事儿就交给Spring Security好了。

SpringSecurity总结

重点回顾：

什么是认证、授权、会话。
Java Servlet为支持http会话做了哪些事儿。
基于session认证机制的运作流程。
基于token认证机制的运作流程。
理解Spring Security的工作原理，Spring Security结构总览，认证流程和授权，中间涉及到哪些组件，这些组件分别处理什么，如何自定义这些组件满足个性需求。
OAuth2.0认证的四种模式？它们的大体流程是什么？
Spring cloud Security OAuth2包括哪些组件？职责？
分布式系统认证需要解决的问题？
掌握学习方法，掌握思考方式。

HttpSecurity配置列表：

总结：

Spring Security 参考手册中文文档

Spring Security OAuth2.0认证授权知识概括相关推荐

Spring Security OAuth2.0认证授权五：用户信息扩展到jwt
历史文章 [Spring Security OAuth2.0认证授权一:框架搭建和认证测试] [Spring Security OAuth2.0认证授权二:搭建资源服务] [Spring Securi ...
Spring Security OAuth2.0认证授权三：使用JWT令牌
历史文章 [Spring Security OAuth2.0认证授权一:框架搭建和认证测试] [Spring Security OAuth2.0认证授权二:搭建资源服务] 前面两篇文章详细讲解了如何基 ...
Spring Security OAuth2.0认证授权
文章目录 1.基本概念 1.1.什么是认证 1.2 什么是会话 1.3什么是授权 1.4授权的数据模型 1.4 RBAC 1.4.1 基于角色的访问控制 2.基于Session的认证方式 3.整合案例 ...
基于Session的认证方式_实现授权功能_Spring Security OAuth2.0认证授权---springcloud工作笔记118
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 我们来实现基本的,session的授权功能,很简单实际上就是利用了springmvc的拦截器.不多 ...
基于Spring Security的认证方式_创建工程_Spring Security OAuth2.0认证授权---springcloud工作笔记119
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 首先加入依赖,除了以前的springmvc的依赖,还要security的依赖,这一次然后这里配置 ...
Spring Security OAuth2.0_实现分布式认证授权_集成测试_Spring Security OAuth2.0认证授权---springcloud工作笔记155
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 然后前面我们已经把分布式微服务的,认证授权全部集成了,然后我们来测试. 启动资源微服务order微 ...
OAuth2.0_环境介绍_授权服务和资源服务_Spring Security OAuth2.0认证授权---springcloud工作笔记138
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 环境介绍 1.可以看到客户端首先访问/oauth/token 这个路径来请求令牌,这个接口是spr ...
OAuth2.0_环境搭建_Spring Security OAuth2.0认证授权---springcloud工作笔记139
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 注意因为springsecurity,本身支持oauth2.0的协议.所以这里可以说springs ...
OAuth2.0_介绍_Spring Security OAuth2.0认证授权---springcloud工作笔记137
技术交流QQ群[JAVA,C++,Python,.NET,BigData,AI]:170933152 上面是oauth2.0的一些介绍. 我们说一下oauth2.0的一个验证的过程, oauth2.0 ...

Spring Security OAuth2.0认证授权知识概括

Spring Security OAuth2.0认证授权知识概括

安全框架基本概念

基于Session的认证方式

Spring Security简介

SpringSecurity详解

分布式系统认证方案

OAuth2.0

Spring Cloud Security OAuth2

JWT令牌

Spring Security实现分布式系统授权

SpringSecurity总结

Spring Security OAuth2.0认证授权知识概括相关推荐

最新文章

热门文章