认证 和 鉴权
认证：简单来说，认证这个用户是谁。
鉴权：简单来说，就是了解这个用户能做什么事情
单体应用
传统的单体应用，一般会写一个固定的认证和鉴权的包，里面包含很多的认证和鉴权的类，当用户请求时可以利用session的方式，把用户存入session并生成一个sessionid，之后返回客户端。客户端可以存在cookie里，从而在后续的请求中顺利通过验证。
常用框架：shiro 、自定义注解、Filter拦截等
SpringCloud认证和鉴权方案
当一个单体应用，拆分成多个微服务时，认证 和 鉴权 就变得复杂
常用方式
分布式Session与网关结合方案
微服务下的SSO单点登陆方案
客户端Token与 网关结合方案
浏览器Cookie与网关结合方案
网关Token和 服务间鉴权结合
。。。。。。。
分布式Session与网关结合方案
用户在网关进行sso登陆 ，进行用户认证，检查用户是否存在和有效
如何用户通过，则将用户信息存储在第三方中间件中，如mysql、redis
后端可以从共享存储拿到用户的数据
很多 场景下，这种方案是推荐的，因为方便扩展，也 可以保证高可用的方案。但是这种方案的缺点是依赖于第三方中间件，且这些部件需要 做高可用，并且增加安全的控制，所有对于实现有一定的复杂度
微服务下的SSO单点登陆方案
单点登录(Single Sign On),简称为 SSO,是目前比较流行的企业业务 整合的解决方案之一。SSO的定义是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统，如CAS（Central Authentication Service），是耶鲁大学开发的单点登录系统（SSO，single sign-on），应用广泛，具有独立于平台的，易于理解，支持代理功能。
但是针对微服务(服务之间调用)：每个 服务都进行每个用户端 的sso动作，那么每个服务里都会做用户的认证和鉴权，可能保存每个用户的信息或者每个用户都会和鉴权服务打交道，这些情况都会带来非常大的网路开销和性能消耗，也有可能会造成数据的不一致，所以不建议用这种方案。
客户端Token与 网关结合方案（jwt）
实现步骤
客户端持有一个token，通常可用jwt或者其它加密的算法实现自己的一种Token，然后通过token保存用户的信息
发起用户请求并携带token，token传到网关层后，网关 层进行认证和校验。
校验通过，携带token到后端服务中
如果涉及到用户的大量信息存放，token就有可能不太合适（或者用中间件来存放）
这种方案也是业界很常用的方案，但是对于 token来说，他的注销有一定的麻烦，需要在网关层进行Token的注销
不推荐使用
浏览器Cookie与网关结合方案
这种方式和上面的方式类似，但不同的是我们把用户的信息存放在cookie里，然后通过网关来解析cookie，从而 获取用户的相关信息，这种方式在一些老系统做改造时遇到的比较多，适合做为老系统改造时采取的方案，因为很多系统需要继承，这时cookie在别的系统中也是同样的适用。
网关Token和 服务间鉴权结合
我们都知道网关适合做认证和鉴权，但是在安全层面，我们要求更严格的权限，对于有些项目来说，本身网络跟外部隔离，再加上其它的安全手段，所以我们只要求在网关上鉴权就可以了。
但是有些时候服务对 服务之间的调用进行鉴权，知道某个用户是否有权限调用某个接口，这些都需要进行鉴权。
这时的方案如下。
1）在gateway网关层做认证，通过用户校验后，传递用户信息到header中，后台做服务在收到header后进行解析，解析完后查看是否有调用此服务或者某个url的权限，然后完成鉴权
2）从服务内部发出的请求，在出去时进行拦截，把用户信息保存在header里，然后传出去,被调用方取到header后进行解析和鉴权
感谢：
https://cloud.tencent.com/developer/article/1430886