认证和授权什么是认证？用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问什么是授权？认证是为了保证用户身份的合法性，授权则是为了更细粒度的对隐私数据进行划分，授权是在认证通过后发生的， 控制不同的用户能够访问不同的资源。
授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有权限则拒绝访问认证 (Authentication) 和授权 (Authorization)的区别是什么？Authentication（认证） 是验证您的身份的凭据
（例如用户名/用户ID和密码），通过这个凭据，系统得以知道你就是你，也就是说系统存在你这个用户所以，Authentication 被称为身份/用户验证Authorization（授权） 发生在 Authentication（认证） 之后。
它主要掌管我们访问系统的权限比如有些特定资源只能具有特定权限的人才能访问比如admin，有些对系统资源操作比如删除、添加、更新只能特定人才具有什么是会话？用户认证通过后，为了避免用户的每次操作都进行认证可将用户的信息保证在会话中。
会话就是系统为了保持当前 用户的登录状态所提供的机制，常见的有基于session方式、基于token方式等什么是Cookie ? Cookie的作用是什么?Cookies是某些网站为了辨别用户身份而储存在用户本地终端上的数据（通常经过加密）。
简单来说： Cookie 存放在客户端，一般用来保存用户信息如何在服务端使用Cookie？给客户端返回cookie首先通过Cookie对象来设置用户信息，然后将其放入到HttpServletResponse对象中，然后返回给前端。
获取特定的cookie值使用Spring框架提供的@CookieValue注解获取特定的 cookie的值读取所有的 Cookie 值Cookie 和 Session 有什么区别？Session 的主要作用就是通过服务端记录用户的状态。
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
相对来说 Session 安全性更高如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密如果没有Cookie的话Session还能用吗？
一般是通过 Cookie 来保存 SessionID ，假如你使用了 Cookie 保存 SessionID的方案的话， 如果客户端禁用了Cookie，那么Seesion就无法正常工作但是，并不是没有 Cookie 之后就不能用 Session 了，。
比如你可以将SessionID放在请求的 url 里面https://javaguide.cn/?session_id=xxx 这种方案的话可行，但是安全性和用户体验感降低当然，为了你也可以对 SessionID 进行一次加密之后再传入后端。
为什么Cookie 无法防止CSRF攻击，而token可以？CSRF（Cross Site Request Forgery）一般被翻译为 跨站请求伪造 那么什么是 跨站请求伪造 呢？说简单用你的身份去发送一些对你不友好的请求。
进行Session 认证的时候，我们一般使用 Cookie 来存储 SessionId,当我们登陆后后端生成一个SessionId放在Cookie中返回给客户端，服务端通过Redis或者其他存储工具记录保存着这个Sessionid，客户端登录以后每次请求都会带上这个SessionId，服务端通过这个SessionId来标示你这个人。
如果别人通过 cookie拿到了 SessionId 后就可以代替你的身份访问系统了但是，我们使用 token 的话就不会存在这个问题，在我们登录成功获得 token 之后，一般会选择存放在 local storage 中。
说下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的方式更适合什么是RBAC?业界通常基于RBAC实现授权基于角色的访问控制RBAC基于角色的访问控制（Role-Based Access Control）是按角色进行授权。
，比如：主体的角色为总经理可以查 询企业运营报表，查询员工工资信息等，访问控制流程如下：基于资源的访问控制RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权
，比如：用户必须 具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：什么是 JWT？它有什么优点？JSON Web Token（JWT）是一个开放的行业标准（RFC 7519），它定义了一种简介的、自包含的协议格式，用于 在通信双方传递json对象，传递的信息经过数字签名可以被验证和信任。
JWT可以使用HMAC算法或使用RSA的公 钥/私钥对来签名，防止被篡改JWT 本质上就一段签名的 JSON 格式的数据JWT 由 3 部分构成：Header :描述 JWT 的元数据定义了生成签名的算法以及 Token 的类型。
Payload（负载）:用来存放实际需要传递的数据Signature（签名）：服务器通过Payload、Header和一个密钥(secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。
优点：1. jwt基于json，非常方便解析可以在令牌中自定义丰富的内容，易扩展通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高资源服务使用JWT可不依赖认证服务即可完成授权什么是 SSO?SSO(Single Sign On)即单点登录说的是用户登陆多个子系统的其中一个就有权访问与其相关的其他系统。
Spring SecuritySpring Security是什么?Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC，DI(控制反转Inversion of Control ,DI:Dependency Injection 依赖注入)和AOP(面向切面编程)功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。
Spring如何管理过滤器Filter？Spring Security所解决的问题就是安全访问控制，而安全访问控制功能其实就是对所有进入系统的请求进行拦截， 校验每个请求是否能够访问它所期望的资源而Spring Security对Web资源的保护是靠Filter实现的。
当初始化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）进行处理。
Spring security 过滤器链中都有哪些filter？它们的作用分别是什么？SecurityContextPersistenceFilter ：这个Filter是整个拦截过程的入口和出口（也就是第一个和最后一个拦截 器），会在请求开始时从配置好的 SecurityContextRepository 中获取 SecurityContext，然后把它设置给 SecurityContextHolder。
在请求完成后将 SecurityContextHolder 持有的 SecurityContext 再保存到配置好的 SecurityContextRepository，同时清除 securityContextHolder 所持有的 SecurityContext；。
UsernamePasswordAuthenticationFilter ：用于处理来自表单提交的认证该表单必须提供对应的用户名和密码，其内部还有登录成功或失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureHandler，这些都可以根据需求做相关改变；。
FilterSecurityInterceptor： 是用于保护web资源的，使用AccessDecisionManager对当前用户进行授权访问；ExceptionTranslationFilter： 能够捕获来自 FilterChain 所有的异常，并进行处理。
但是它只会处理两类异常： AuthenticationException 和 AccessDeniedException，其它的异常它会继续抛出Spring Security的认证流程是什么？用户提交用户名、密码被SecurityFilterChain中的 UsernamePasswordAuthenticationFilter 过滤器获取到， 封装为请求Authentication，通常情况下是UsernamePasswordAuthenticationToken这个实现类。
然后过滤器将Authentication提交至认证管理器（AuthenticationManager）进行认证 认证成功后， AuthenticationManager 身份管理器返回一个被填充满了信息的（包括上面提到的权限信息， 身份信息，细节信息，但密码通常会被移除） Authentication 实例。
SecurityContextHolder 安全上下文容器将第3步填充了信息的 Authentication ，通过 SecurityContextHolder.getContext().setAuthentication(…)方法，设置到其中。
可以看出AuthenticationManager接口（认证管理器）是认证相关的核心接口，也是发起认证的出发点，它 的实现类为ProviderManager而Spring Security支持多种认证方式，因此ProviderManager维护着一个 List 列表，存放多种认证方式，最终实际的认证工作是由 AuthenticationProvider完成的。
咱们知道web表单的对应的AuthenticationProvider实现类为 DaoAuthenticationProvider，它的内部又维护着一个UserDetailsService负责UserDetails的获取。
最终 AuthenticationProvider将UserDetails填充至AuthenticationOAuth2.0OAuth2.0是什么？OAuth 简单理解就是一种授权机制，它是在客户端和资源所有者之间的授权层，用来分离两种不同的角色。
在资源所有者同意并向客户端颁发令牌后，客户端携带令牌可以访问资源所有者的资源OAuth2.0的原理是什么？OAuth在第三方应用与服务提供商之间设置了一个授权层第三方应用不能直接登录服务提供商，只能登录授权层，以此将用户与客户端区分开来。
第三方应用登录授权层所用的令牌，与用户的密码不同用户可以在登录授权的时候，指定授权层令牌的权限范围和有效期 第三方应用登录授权层以后，服务提供商根据令牌的权限范围和有效期，向第三方应用开放用户资源OAuth2.0都有哪些注解？。
@EnableAuthorizationServer认证授权服务，提供用于获取token，解析token相关功能，实现认证、授权功能@EnableResourceServer资源服务，提供基于token的资源访问功能。
@EnableOAuth2Sso应用系统，使用远端认证授权服务，替换应用自身的用户登录鉴权security逻辑，实现单点登录功能简要步骤：访问应用系统资源-> 应用系统发现未登录-> 302 跳转到登录页面（登录页面地址已经与获取token逻辑自动关联）-> 应用系统发现符合获取token条件，根据授权类型拼装url->302 跳转到认证授权地址（认证授权服务提供）进行认证、授权。
OAuth2.0都需要哪些配置类？ClientDetailsServiceConfigurer：用来配置客户端详情服务（ClientDetailsService），客户端详情信息在 这里进行初始化，你能够把客户端详情信息写死在这里或者是通过数据库来存储调取详情信息。
AuthorizationServerEndpointsConfigurer：用来配置令牌（token）的访问端点和令牌服务(token services)AuthorizationServerSecurityConfigurer：用来配置令牌端点的安全约束.。
OAuth2.0的认证流程?用户打开客户端以后，客户端要求用户给予授权用户同意给予客户端授权客户端使用上一步获得的授权，向认证服务器申请令牌认证服务器对客户端进行认证以后，确认无误，同意发放令牌客户端使用令牌，向资源服务器申请获取资源。
资源服务器确认令牌无误，同意向客户端开放资源OAuth 2.0的四种授权方式都有哪些？授权码模式简化模式密码模式客户端模式说下授权码模式流程和使用场景？授权码流程：（1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会 附加客户端的身份信息。
如：/uaa/oauth/authorize?client_id=c1&response_type=code&scope=all&redirect_uri=http://www.baidu.com参数列表如下：。
client_id：客户端准入标识response_type：授权码模式固定为codescope：客户端权限redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。
（2）浏览器出现向授权服务器授权页面，之后将用户同意授权 （3）授权服务器将授权码（AuthorizationCode）转经浏览器发送给client(通过redirect_uri) （4）客户端拿着授权码向授权服务器索要访问access_token。
，请求如下：/uaa/oauth/token? client_id=c1&client_secret=secret&grant_type=authorization_code&code=5PgfcD&redirect_uri=http:/
/w ww.baidu.com参数列表如下client_id：客户端准入标识client_secret：客户端秘钥grant_type：授权类型，填写authorization_code，表示授权码模式。
code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致（5）授权服务器返回令牌(access_token)。
。
使用场景：这种模式是四种模式中最安全的一种模式一般用于client是Web服务器端应用或第三方的原生App调用资源服务的时候因为在这种模式中access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减小了令牌泄漏的风险。
说下简化模式流程和使用场景？（1）资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会 附加客户端的身份信息如：/uaa/oauth/authorize?client_id=c1&response_type=token&scope=all&redirect_uri=http:/。
/www.baidu.com参数描述同授权码模式 ，注意response_type=token，说明是简化模式（2）浏览器出现向授权服务器授权页面，之后将用户同意授权（3）授权服务器将授权码将令牌（access_token）以Hash的形式存放在重定向uri的fargment中发送给浏览器。
注：fragment 主要是用来标识 URI 所标识资源里的某个资源，在URI 的末尾通过 （#）作为 fragment 的开头， 其中 # 不属于 fragment 的值如https://domain/index#L18这个 URI 中 L18 就是 fragment 的值。
大家只需要 知道js通过响应浏览器地址栏变化的方式能获取到fragment 就行了
使用场景：一般来说，简化模式用于没有服务器端的第三方单页面应用，因为没有服务器端就无法接收授权码说下密码模式流程和使用场景？（1）资源拥有者将用户名、密码发送给客户端（2）客户端拿着资源拥有者的用户名、密码向授权服务器请求令牌（access_token）。
，请求如下：/uaa/oauth/token? client_id=c1&client_secret=secret&grant_type=password&username=shangsan&password=123
参数列表如下：client_id：客户端准入标识client_secret：客户端秘钥grant_type：授权类型，填写password表示密码模式 username：资源拥有者用户名 password：资源拥有者密码。
（3）授权服务器将令牌（access_token）发送给client 。
使用场景：这种模式十分简单，但是却意味着直接将用户敏感信息泄漏给了client，因此这就说明这种模式只能用于client是我 们自己开发的情况下因此密码模式一般用于我们自己开发的，第一方原生App或第一方单页面应用。
说下密码模式流程和使用场景？（1）客户端向授权服务器发送自己的身份信息，并请求令牌（access_token） （2）确认客户端身份无误后，将令牌（access_token）发送给client，请求如下：。
/uaa/oauth/token?client_id=c1&client_secret=secret&grant_type=client_credentials参数列表如下：client_id：客户端准入标识。
client_secret：客户端秘钥。grant_type：授权类型，填写client_credentials表示客户端模式。
这种模式是最方便但最不安全的模式因此这就要求我们对client完全的信任，而client本身也是安全的因此这种模式一般用来提供给我们完全信任的服务器端服务比如，合作方系统对接，拉取一组用户信息
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。