江苏做电缆桥架的公司网站,淄博网站开发,群晖系统可以做网站吗,丽水网站建设公司排名戳蓝字“CSDN云计算”关注我们哦#xff01;作者 | 奎哥来源 | 不止思考应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后#xff0c;项目的复杂度提升了N个级别#xff0c;相应的#xff0c;微服务的安全工作也就更难更复… 戳蓝字“CSDN云计算”关注我们哦作者 | 奎哥来源 | 不止思考应用程序的访问安全又是我们每一个研发团队都必须关注的重点问题。尤其是在我们采用了微服务架构之后项目的复杂度提升了N个级别相应的微服务的安全工作也就更难更复杂了。并且我们以往擅长的单体应用的安全方案对于微服务来说已经不再适用了。我们必须有一套新的方案来保障微服务架构的安全。在探索微服务访问安全之前我们还是先来回顾一下单体应用的安全是如何实现的。一、传统单体应用如何实现「访问安全」下图就是一个传统单体应用的访问示意图图片来自WillTran在slideshare分享在应用服务器里面我们有一个auth模块一般采用过滤来实现当有客户端请求进来时所有的请求都必须首先经过这个auth来做身份验证验证通过后才将请求发到后面的业务逻辑。通常客户端在第一次请求的时候会带上身份校验信息用户名和密码auth模块在验证信息无误后就会返回Cookie存到客户端之后每次客户端只需要在请求中携带Cookie来访问而auth模块也只需要校验Cookie的合法性后决定是否放行。可见在传统单体应用中的安全架构还是蛮简单的对外也只有一个入口通过auth校验后内部的用户信息都是内存/线程传递逻辑并不是复杂所以风险也在可控范围内。那么当我们的项目改为微服务之后「访问安全」又该怎么做呢。二、微服务如何实现「访问安全」在微服务架构下有以下三种方案可以选择当然用的最多的肯定还是OAuth模式。网关鉴权模式API Gateway服务自主鉴权模式API Token模式OAuth2.0下面分别来讲一下这三种模式网关鉴权模式API Gateway图片来自WillTran在slideshare分享通过上图可见因为在微服务的最前端一般会有一个API网关模块API Gateway所有的外部请求访问微服务集群时都会首先通过这个API Gateway所以我们可以在这个模块里部署auth逻辑实现统一集中鉴权鉴权通过后再把请求转发给后端各个服务。这种模式的优点就是由API Gateway集中处理了鉴权的逻辑使得后端各微服务节点自身逻辑就简单了只需要关注业务逻辑无需关注安全性事宜。这个模式的问题就是API Gateway适用于身份验证和简单的路径授权基于URL的对于复杂数据/角色的授权访问权限通过API Gateway很难去灵活的控制毕竟这些逻辑都是存在后端服务上的并非存储在API Gateway里。服务自主鉴权模式图片来自WillTran在slideshare分享服务自主鉴权就是指不通过前端的API Gateway来控制而是由后端的每一个微服务节点自己去鉴权。它的优点就是可以由更为灵活的访问授权策略并且相当于微服务节点完全无状态化了。同时还可以避免API Gateway 中 auth 模块的性能瓶颈。缺点就是由于每一个微服务都自主鉴权当一个请求要经过多个微服务节点时会进行重复鉴权增加了很多额外的性能开销。API Token模式OAuth2.0图片来自网络如图这是一种采用基于令牌Token的授权方式。在这个模式下是由授权服务器图中Authorization Server、API网关图中API Gateway、内部的微服务节点几个模块组成。流程如下第一步客户端应用首先使用账号密码或者其它身份信息去访问授权服务器Authorization Server获取 访问令牌Access Token。第二步拿到访问令牌Access Token后带着它再去访问API网关图中API GatewayAPI Gateway自己是无法判断这个Access Token是否合法的所以走第三步。第三步API Gateway去调用Authorization Server校验一下Access Token的合法性。第四步如果验证完Access Token是合法的那API Gateway就将Access Token换成JWT令牌返回。注意此处也可以不换成JWT而是直接返回原Access Token。但是换成JWT更好因为Access Token是一串不可读无意义的字符串每次验证Access Token是否合法都需要去访问Authorization Server才知道。但是JWT令牌是一个包含JOSN对象有用户信息和其它数据的一个字符串后面微服务节点拿到JWT之后自己就可以做校验减少了交互次数。第五步API Gateway有了JWT之后就将请求向后端微服务节点进行转发同时会带上这个JWT。第六步微服务节点收到请求后读取里面的JWT然后通过加密算法验证这个JWT验证通过后就处理请求逻辑。这里面就使用到了OAuth2.0的原理不过这只是OAuth2.0各类模式中的一种。由于OAuth2.0目前最为常用所以接下来我再来详细讲解一下OAuth2.0的原理和各类用法。三、详解 OAuth2.0 的「 访问安全 」OAuth2.0是一种访问授权协议框架。它是基于Token令牌的授权方式在不暴露用户密码的情况下使 应用方 能够获取到用户数据的访问权限。例如你开发了一个视频网站可以采用第三方微信登陆那么只要用户在微信上对这个网站授权了那这个网站就可以在无需用户密码的情况下获取用户在微信上的头像。OAuth2.0 的流程如下图OAuth2.0 里的主要名词有资源服务器用户数据/资源存放的地方在微服务架构中服务就是资源服务器。在上面的例子中微信头像存放的服务就是资源服务器。资源拥有者是指用户资源的拥有人。在上面的例子中某个微信头像的用户就是资源拥有者。授权服务器是一个用来验证用户身份并颁发令牌的服务器。客户端应用想要访问用户受保护资源的客户端/Web应用。在上面的例子中的视频网站就是客户端应用。访问令牌Access Token授予对资源服务器的访问权限额度令牌。刷新令牌客户端应用用于获取新的 Access Token 的一种令牌。客户凭证用户的账号密码用于在 授权服务器 进行验证用户身份的凭证。OAuth2.0有四种授权模式也就是四种获取令牌的方式授权码、简化式、用户名密码、客户端凭证。下面来分别讲解一下授权码Authorization Code授权码模式是指客户端应用先去申请一个授权码然后再拿着这个授权码去获取令牌的模式。这也是目前最为常用的一种模式安全性比较高适用于我们常用的前后端分离项目。通过前端跳转的方式去访问 授权服务器 获取授权码然后后端再用这个授权码访问 授权服务器 以获取 访问令牌。流程如上图。第一步客户端的前端页面(图中UserAgent)将用户跳转到 授权服务器(Authorization Server)里进行授权授权完成后返回 授权码(Authorization Code)第二步客户端的后端服务(图中Client)携带授权码(Authorization Code)去访问 授权服务器然后获得正式的 访问令牌(Access Token)页面的前端和后端分别做不同的逻辑前端接触不到Access Token保证了Access Token的安全性。简化式Implicit简化模式是在项目是一个纯前端应用在没有后端的情况下采用的一种模式。因为这种方式令牌是直接存在前端的所以非常不安全因此令牌的有限期设置就不能太长。其流程就是第一步应用纯前端的应用将用户跳转到 授权服务器(Authorization Server)里进行授权授权完成后授权服务器 直接将 Access Token 返回给 前端应用令牌存储在前端页面。第二步应用纯前端的应用携带 访问令牌(Access Token) 去访问资源获取资源。在整个过程中虽然令牌是在前端URL中直接传递但注意令牌在HTTP协议中不是放在URL参数字段中的而是放在URL锚点里。因为锚点数据不会被浏览器发到服务器因此有一定的安全保障。用户名密码Resource Owner Credentials这种方式最容易理解了直接使用用户的用户名/密码作为授权方式去访问 授权服务器从而获取Access Token这个方式因为需要用户给出自己的密码所以非常的不安全性。一般仅在客户端应用与授权服务器、资源服务器是归属统一公司/团队互相非常信任的情况下采用。客户端凭证Client Credentials这是适用于服务器间通信的场景。客户端应用拿一个用户凭证去找授权服务器获取Access Token。以上就是对微服务架构中「访问安全」的一些思考。在微服务架构的系列文章中前面已经通过文章介绍过了「服务注册 」、「服务网关 」、「配置中心 」、「 监控系统 」、「调用链监控」、「容错隔离」大家可以翻阅历史文章查看。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读听说私有云也出新一代了搞不懂SDN那是因为你没看这个小故事…华为最强自研 NPU 问世麒麟 810 “抛弃”寒武纪北邮通信博士万字长文带你秒懂 4G/5G 区别LinkedIn最新报告: 区块链成职位需求增长最快领域, 这些地区对区块链人才渴求度最高……中文NLP的分词真有必要吗李纪为团队四项任务评测一探究竟 | ACL 20196月技术福利限时免费领真香朕在看了
