13权限认证分布式session替代方案_第1页
13权限认证分布式session替代方案_第2页
13权限认证分布式session替代方案_第3页
13权限认证分布式session替代方案_第4页
全文预览已结束

下载本文档

版权说明：本文档由用户提供并上传，收益归属内容提供方，若内容存在侵权，请进行举报或认领

文档简介

sessionsession复制的方法来说，绑定IP的方式有更明显的缺陷：IP的情况下无法在网关层应用负载均衡策略，而且某个服务器出现故障的话会对指定IP段的来访用户产生较大影响。对网关层IPIP，这就会导致更换IP后的session为了解决第二个问题，可以通过一致性HashID做Hash，不同的HashIP切Redis这个方案解决了前面提到的大部分问题，session不再保存在服务器上，取而代之的是保存在redis中，所有的服务器都向redis写入/读取缓存信息。在Tomcat层面，我们可以直接引入tomcat-redis-session-manager组件，将容器层面sessionredis的组件，但是这种方案和容器绑定的比较紧密。另一个更优雅的方案是借助spring-sessionredissession，尽管这个方案脱离了具体Session的用户鉴权方案，这类Session方案已经在微服务应用中被Tothinkoutofboxguys~session个鉴权方案-OAuth2.0。OAuth2.0是一个开放授权标准协议，它允许用户让第三方应用访问该用户在某服务的特个第三方应用，我们通过OAuth2.0AuthGrant在这一步Client发起AuthorizationRequest（比如通过微信内扫码授权AuthGetToken客户端拿着从微信获取到的AuthGrant，发给第三方引用的鉴权服务，换取一个Token，这个Token就是访问第三方应用资源所需Token令牌，服务组件搭建OAuth2.0的鉴权服务，OAuth2.0的协议还涉及到很多复杂的规范，比如角来看另外一个更轻量级的授权方案：JWT鉴权。JWT的基本思想就是通过用户名+密码换取一个AccessToken。用户名+密码访问鉴权服务验证通过：服务器返回一个Access给客户端，并将token保存在服务端某个地方用于后面的访问控制（可以保存在数据库或者Redis中）验证失败：不生成JWTAccessToken由三个部分构成，分别是Header、PayloadSignature，我们分Header头部声明了Token的类型（JWT类型）{'typ':'alg':}Payload这一段包含的信息相当丰富，你可以定义Token收到Token的时候也同样可以对Payload中包含的信息做验证，比如说某个Token的签发者是“Feign-API”，假如某个接口只能允许“Gateway-API”签发的Token，那么在做鉴权服务时就可以加入Issuer的判断逻辑。SignatureHeader和Payload以及一个密钥用来生成签证信息，这一步会使用Header里我们指定的加密算法进行加密实现的依赖项到项目中的po

人人文库> 全部分类> 教育资料 > 课件下载

温馨提示

  • 1. 本站所有资源如无特殊说明，都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等，如果需要附件，请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸，网页内容里面会有图纸预览，若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对用户上传分享的文档内容本身不做任何修改或编辑，并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容，请与我们联系，我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论