Java权限认证框架比较

认证、授权、鉴权和权限控制

	定义	英文	实现方式
认证	确认声明者的身份	identification	根据声明者独特的识别信息
授权	获取用户的委派权限	authorization	颁发一个授信媒介，不可被篡改，不可伪造，受保护
鉴权	对所声明的权限真实性进行鉴别的过程权限是一个抽象的逻辑概念，定义和配置可执行的操作，而控制是具体的实现方式，通过一定的方式控制操作的允许和禁止	authentication	鉴权和授权是一一对应关系，解析授信媒介，确认其合法性、有效性
权限控制	权限是一个抽象的逻辑概念，定义和配置可执行的操作，而控制是具体的实现方式，通过一定的方式控制操作的允许和禁止	access/permission control	实现方式多样，根据具体情况来实现。

为什么需要权限管理？

• 安全性：误操作，人为破坏，数据泄露等

• 数据隔离：不同的权限能看到及操作不同的数据

• 明确的职责：运营，客服等不同角色，leader和dev等不同级别。

权限管理核心

基于角色的访问权限控制(RBAC)模型，赋予用户的权限管理，可以分为三大类型：

1. 功能权限： 功能权限是系统执行权限控制的基本单元。针对功能模块来划分用户权限是比较粗颗粒度的一种划分方式。不同角色的用户查看相同的数据字段，但可执行的功能操作不同

2. 数据权限：数据字段权限是较细颗粒度，实现不同角色用户进入同一模块时，受限于不同的角色权限可见的数据字段都有差异

3. 菜单权限：控制当前账号可以看到的菜单页面内容

开源权限认证：Spring Security 和 Apache shiiro

查看基于springboot实现微服务之间FeignClient调用，免认证的功能

1 JWT权限认证

1.1 权限认证使用JWT，支持多终端认证系统

1. JWT又名Json Web Token，基于数字签名，定义了一个紧凑、字包含的方式，用于json在各方之间安全传输信息。
2. 使用场景：一般用于授权认证和数据交换；Authorization(授权)是使用JWT的最常见场景。
    a. 一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。
    b. 单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松的跨域使用。

1.2 JWT工作流程：

1. 用户携带用户名和密码请求访问
2. 服务器校验用户凭据
3. 应用提供一个token给客户端
4. 客户端存储token，并且在随后的每一次请求中都带着它
5. 服务器校验token并返回数据

1.3 JWT的好处：

1. token存放在客户端，减轻服务器端的负担，可以让负载均衡器将用户传递到任意服务器
2. 每次请求都需要带上token，没有会话，安全性大

1.4 和老版本的session相比的优点

因为http是无状态的，无法记录请求方，于是大家都会发送cookie到服务器端，或者是在服务器端上记录sessionId
问题点：
1. 服务器端记录大量的sessionid，对内存开销有影响
2. 跨域问题
3. 安全性

2 Spring Security

2.1 Security说明

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。
它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC（控制反转），DI（ 依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
它是一个轻量级的安全框架，它确保基于Spring的应用程序提供身份验证和授权支持。
它与Spring MVC有很好地集成，并配备了流行的安全算法实现捆绑在一起。
安全主要包括两个操作“认证”与“验证”（有时候也会叫做权限控制）。
“认证”是为用户建立一个其声明的角色的过程，这个角色可以一个用户、一个设备或者一个系统。
“验证”指的是一个用户在你的应用中能够执行某个操作。在到达授权判断之前，角色已经在身份认证过程中建立了。

它的设计是基于框架内大范围的依赖的，可以被划分为以下几块：

1. Web/Http 安全：这是最复杂的部分。通过建立 filter 和相关的 service bean 来实现框架的认证机制。当访问受保护的 URL 时会将用户引入登录界面或者是错误提示界面。
2. 业务对象或者方法的安全：控制方法访问权限的。
3. AuthenticationManager：处理来自于框架其他部分的认证请求。
4. AccessDecisionManager：为 Web 或方法的安全提供访问决策。会注册一个默认的，但是我们也可以通过普通 bean 注册的方式使用自定义的 AccessDecisionManager。
5. AuthenticationProvider：AuthenticationManager 是通过它来认证用户的。
6. UserDetailsService：跟 AuthenticationProvider 关系密切，用来获取用户信息的

2.2 工作原理及应用范围

Spring security 是基于filter的，filter按照顺序去执行，根据filterChain去调用下一个filter，Spring Security 在 Filter 中创建 Authentication 对象，并调用 AuthenticationManager 进行校验。Spring Security有一个filterChain去管理filter，根据需要的功能在配置中配置。
流程
1. spring security 的核心是基于filter
2. 入口filter是springSecurityFilterChain(它会被DelegatingFilterProxy委托来执行过滤任务)
3. springSecurityFilterChain实际上是FilterChainProxy （一个filter）
4. FilterChainProxy里边有一个SecurityFilterChain集合，doFIlter的时候会从其中取

3 Shiro(对非spring框架兼容性更好)

3.1 Shiro说明

Apache Shiro是Java的一个安全框架，在轻量级的程序应用更广泛，简化了Spring security的功能，提供了处理身份认证，授权，企业会话管理和加密的功能。
应用领域
1. 验证用户
2. 对用户执行访问控制，如：
3. 判断用户是否拥有角色admin。
4. 判断用户是否拥有访问的权限
5. 在任何环境下使用 Session API。例如CS程序。
6. 可以使用多个用户数据源。例如一个是oracle用户库，另外一个是mysql用户库。
7. 单点登录（SSO）功能。
8. “Remember Me”服务 ，类似购物车的功能，shiro官方建议开启

4 shiro和spring security差别

1. shiro配置更加容易理解，容易上手；security配置相对比较难懂。
2. 在spring的环境下，security整合性更好。Shiro对很多其他的框架兼容性更好，号称是无缝集成。
3. shiro 不仅仅可以使用在web中，它可以工作在任何应用环境中。
4. 在集群会话时Shiro最重要的一个好处或许就是它的会话是独立于容器的。
5. Shiro提供的密码加密使用起来非常方便。
6. 控制精度： 注解方式控制权限只能是在方法上控制，无法控制类级别访问。

相关博客详解：https://blog.csdn.net/qq_33407429/article/details/99640734

5 Spring Security OAuth2.0

1、Spring Security-OAuth2是对OAuth2的一种实现，跟SpringSecurity相辅相成，与Spring Cloud体系的集成也非常便利。

2、OAuth2.0的服务提供方涵盖两个服务，即授权服务(Authorization Server，也叫认证服务）和资源服务（Resource Server），使用SpringSecurity OAuth2的时候你可以选择把他们在同一个应用程序中实现，也可以选择建立使用同一个授权服务的多个资源服务。

3、授权服务(Authorization Server) 应包含对接入端以及登入用户的合法性进行验证并且颁发token等功能，对令牌的请求端点由SpringMVC控制器进行实现，下面是配置一个认证服务必须要实现的endpoints：

• AuthorizationEndpoint服务于认证请求，默认URL：/oauth/authorize
• TokenEndpoint服务于访问令牌的请求：默认URL：/oauth/token
• 资源服务(Resource Server)，应包含对资源的保护功能，对非法请求进行拦截，对请求中token进行解析鉴权等。
• OAuth2AuthenticationProcessingFilter用来对请求给出的身份令牌解析鉴权。

4、认证流程如下：

• 客户端请求授权服务进行认证，认证通过后拿到令牌Token
• 客户端携带令牌Token请求资源服务
• 资源服务校验令牌的合法性，合法即返回资源信息

6 单点登录

6.1 SSO单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。

SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

例如：

在浏览器登录了淘宝，再打开天猫、支付宝、阿里巴巴，都会实现自动登录；

在学校登录了OA系统，再打开科研、教务系统，都会实现自动登录。

简而言之，多个系统，统一登陆。（单点登录主要强调的是登录以后，各个系统间数据共享问题。）

SSO单点登录与CAS 和OAuth之间有什么区别

SSO仅仅是一种设计架构，而CAS和OAuth是SSO的一种实现方式，他们之间是抽象与具象的关系。

1、CAS 中央认证服务（Central Authentication Service）

• CAS是由美国耶鲁大学发起的一个企业级开源项目，旨在为WEB应用系统提供一种可靠的单点登录解决方案（WEB SSO）。
• CAS由CAS Server和CAS Client两部分组成。

2、OAuth2.0 开放授权（Open Authorization）

• OAuth2.0是一个为用户资源授权定义的安全标准，主要用于第三方应用授权登录，由于OAuth1.0标准存在安全漏洞现在已升级到2.0版本。

6.2 Sa-Token

Sa-Token 是一个轻量级 Java 权限认证框架，让鉴权变得简单、优雅！主要解决：登录认证、权限认证、单点登录、OAuth2.0、分布式Session会话、微服务网关鉴权 等一系列权限相关问题。

Sa-Token 目前主要五大功能模块：登录认证、权限认证、单点登录、OAuth2.0、微服务鉴权。

6.3 OAuth2.0（登录授权）

现象原理

现象：第三方系统访问主系统资源，用户无需将在主系统的账号告知第三方，只需通过主系统的授权，第三方就可使用主系统的资源（如：APP1需使用微信支付，微信支付会提示用户是否授权，用户授权后，APP1就可使用微信支付功能了）

原理：主系统，授权系统（给主系统授权用的，也可以跟主系统是同一个系统），第三方系统

1、第三方系统需要使用主系统的资源，第三方重定向到授权系统

2、根据不同的授权方式，授权系统提示用户授权

3、用户授权后，授权系统返回一个授权凭证（accessToken）给第三方系统【accessToken是有有效期的】

4、第三方使用accessToken访问主系统资源【accessToken失效后，第三方需重新请求授权系统，以获取新的accessToken】

一、授权码模式（authorization code）

1. 这种模式算是正宗的oauth2的授权模式
2. 设计了auth code，通过这个code再获取token
3. 支持refresh token

相对其他三种来说是功能比较完整、流程最安全严谨的授权方式，通过客户端的后台服务器与服务提供商的认证服务器交互来完成。

二、密码模式（resource owner password credentials）

1. 这种模式是最不推荐的，因为client可能存了用户密码
2. 这种模式主要用来做遗留项目升级为oauth2的适配方案
3. 当然如果client是自家的应用，也是可以
4. 支持refresh token

密码模式也是比较常用到的一种，客户端向授权服务器提供用户名、密码然后得到授权令牌。

这种模式有种弊端，就是我们的客户端需要存储用户输入的密码，但是对于用户来说信任度不高的平台是不可能让他们输入密码的。

三、简化模式（implicit）

1. 这种模式比授权码模式少了code环节，回调url直接携带token
2. 这种模式的使用场景是基于浏览器的应用
3. 这种模式基于安全性考虑，建议把token时效设置短一些
4. 不支持refresh token

这种模式不通过服务器端程序来完成，直接由浏览器发送请求获取令牌，令牌是完全暴露在浏览器中的，这种模式不太安全。

四、客户端模式（client credentials）

1. 这种模式直接根据client的id和密钥即可获取token，无需用户参与
2. 这种模式比较合适消费api的后端服务，比如拉取一组用户信息等
3. 不支持refresh token，主要是没有必要

客户端模式是客户端以自己的名义去授权服务器申请授权令牌，并不是完全意义上的授权。

刷新令牌的作用

refresh token的初衷主要是为了用户体验不想用户重复输入账号密码来换取新token，因而设计了refresh token用于换取新token

这种模式由于没有用户参与，而且也不需要用户账号密码，仅仅根据自己的id和密钥就可以换取新token，因而没必要refresh token

6.4 CAS（单点登录）

现象：多个系统只需登录一次，无需重复登录

原理：授权服务器，被授权客户端

1、授权服务器（一个）保存了全局的一份session，客户端（多个）各自保存自己的session

2、客户端登录时判断自己的session是否已登录，若未登录，则（告诉浏览器）重定向到授权服务器（参数带上自己的地址，用于回调）

3、授权服务器判断全局的session是否已登录，若未登录则定向到登录页面，提示用户登录，登录成功后，授权服务器重定向到客户端（参数带上ticket【一个凭证号】）

4、客户端收到ticket后，请求服务器获取用户信息

5、服务器同意客户端授权后，服务端保存用户信息至全局session，客户端将用户保存至本地session

6.5 CAS认证和Oauth2.0认证对比

1、CAS 是支持单点登录的技术框架

2、OAuth2.0 是授权协议

CAS适合场景：多个应用系统，只需要登录一次就可以同样访问其他系统。



如图：CAS它提供了CAS Server 和CAS Client , CAS Server 独立部署， CAS Client 是一个jar 包，导入到项目中，配合 CAS Server 实现多个项目的SSO 。 实现项目之间的SSO技术上有很强的关联性， 各系统的用户名也应该在CAS Server 认证中心存在 ，访问其中某一个项目时，重定向到统一登录页面，登录完成后，带上凭证信息重定向该项目，该项目通过cas client 拦截验证cas server 提供的认证信息，完成当前项目的登录 , CAS比较适合技术体系差不多的公司内部项目做单点登录技术方案。

Oauth2.0场景：希望能给外部系统颁发token，外部系统通过token访问资源服务器的接口。



如图：我想用知乎发文章，但不想再次注册，这个时候可以选择通过QQ登录，这个过程就使用到了Oauth2.0授权。

7 单一登录

现象：同一系统，同一用户在同一时间内只能有一个会话（即一个用户只有一个在使用的浏览器）

原理：

1、把登录成功的用户放入session和缓存，缓存中格式：key:userID,value:sessionId

2、用户访问资源时，用拦截器（或过滤器）拦截用户请求，先判断用户是否已登录（根据session判断），若用户未登录，则定向到登录页面提示用户登录

3、若用户session已登录，根据用户userID取出缓存数据，判断当前浏览器的sessionId与缓存的是否一致，若一致，则继续访问

4、若sessionId不一致，则将当期的session数据清空，用户登出，提示用户被踢出