auth2.0机制 以及jwt

具体来说，auth2.0一共分成四种授权类型

第一种是授权码模式，这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。比如A应用想要获取B应用的用户数据，A会首先访问B的授权页面，用户点击确认授权之后，B会请求A配置的回调地址，同时附带上授权码code，A可以通过这个code向B申请登录令牌access_token，获取到登录令牌之后，然后就可以向B应用请求用户信息数据了。最常见的就是微信登陆等第三方登录都用的这种方式。

还有就是简化模式：

密码式

客户端凭证等三种模式

 

系统架构层面的问题说说jwt

微服务集群中的每个服务，对外提供的都是Rest风格的接口。而Rest风格的一个最重要的规范就是：服务的无状态性，即：

服务端不保存任何客户端请求者信息客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份，一般这里就是token登陆令牌这样做的话，会有很多好处，比如

客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务服务端的集群和状态对客户端透明服务端可以任意的迁移和伸缩减小服务端存储压力

我们项目中也是采用的无状态登陆，使用token作为身份认证的令牌，这个token就是使用jwt生成的，jwt类型的token分为三部分，头部，载荷，签名，头部存储一些识别信息，载荷存储一些用户的基本字段，我们存储的是id的username，签名是通过头部和载荷外加RAS非对称加密生成的

 

 

单点登录sso

传统的单站点登录访问授权机制是：登录成功后将用户信息保存在session中，sessionId保存在cookie中，每次访问需要登录访问的资源(url)时判断当前session是否为空，为空的话跳转到登录界面登录，不为空的话允许访问。

 单点登录是一种多站点共享登录访问授权机制，访问用户只需要在一个站点登录就可以访问其它站点需要登录访问的资源(url)。用户在任意一个站点注销登录，则其它站点的登录状态也被注销。简而言之就是：一处登录，处处登录。一处注销，处处注销。

总结：

SSO系统生成一个token，并将用户信息存到Redis中，并设置过期时间

其他系统请求SSO系统进行登录，得到SSO返回的token，写到Cookie中

每次请求时，Cookie都会带上，拦截器得到token，判断是否已经登录

到这里，其实我们会发现其实就两个变化：

将登陆功能抽取为一个系统（SSO），其他系统请求SSO进行登录

本来将用户信息存到Session，现在将用户信息存到Redis