做爰视频在线观看免费网站,电话营销网站建设,电商网站开发面试题,营销型网站的名词解释从单体应用架构到分布式应用架构再到微服务架构#xff0c;应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化#xff0c;身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用#xff0c;如何保证高效安全的身份认证#xff1f;面对外… 从单体应用架构到分布式应用架构再到微服务架构应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用如何保证高效安全的身份认证面对外部的服务访问该如何提供细粒度的鉴权方案本文将会为大家阐述微服务架构下的安全认证与鉴权方案。 单体应用 VS 微服务 随着微服务架构的兴起传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大。单体应用体系下应用是一个整体一般针对所有的请求都会进行权限校验。请求一般会通过一个权限的拦截器进行权限的校验在登录时将用户信息缓存到 session 中后续访问则从缓存中获取用户信息。 而微服务架构下一个应用会被拆分成若干个微应用每个微应用都需要对访问进行鉴权每个微应用都需要明确当前访问用户autheticate以及其权限(authorize)。尤其当访问来源不只是浏览器还包括其他服务的调用时单体应用架构下的鉴权方式就不是特别合适了。在为服务架构下要考虑外部应用接入的场景、用户 - 服务的鉴权、服务 - 服务的鉴权等多种鉴权场景。 David Borsos 在伦敦的微服务大会上提出了四种方案 1. 单点登录SSO 此方案意味着每个面向用户的服务都必须与认证服务交互会产生大量非常琐碎的网络流量和重复的工作当动辄数十个微应用时这种方案的弊端会更加明显。 2. 分布式 Session 方案 分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时用户数据可以从共享存储中获取。在某些场景下这种方案很不错用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制因此需要通过安全链接来访问这时解决方案的实现就通常具有相当高的复杂性了。 3. 客户端 Token 方案 令牌在客户端生成由身份验证服务进行签名并且必须包含足够的信息以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上为微服务提供用户身份验证这种解决方案的安全性相对较好但身份验证注销是一个大问题缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案Borsos 更喜欢使用 JSON Web TokensJWT它足够简单且库支持程度也比较好。 4. 客户端 Token 与 API 网关结合 这个方案意味着所有请求都通过网关从而有效地隐藏了微服务。 在请求时网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下注销就不是问题因为网关可以在注销时撤销用户的令牌。 微服务常见安全认证方案 HTTP 基本认证 HTTP Basic AuthenticationHTTP 基本认证是 HTTP 1.0 提出的一种认证机制这个想必大家都很熟悉了我不再赘述。HTTP 基本认证的过程如下 客户端发送 HTTP Request 给服务器。 因为 Request 中没有包含 Authorization header服务器会返回一个 401 Unauthozied 给客户端并且在 Response 的 Header WWW-Authenticate 中添加信息。 客户端把用户名和密码用 BASE64 加密后放在 Authorization Header 中发送给服务器 认证成功。(注意这一步的表述有问题BASE64不是加密手段而是编码手段) 服务器将 Authorization Header 中的用户名密码取出进行验证 如果验证通过将根据请求发送资源给客户端。 基于 Session 的认证 基于 Session 的认证应该是最常用的一种认证机制了。用户登录认证成功后将用户相关数据存储到 Session 中单体应用架构中默认 Session 会存储在应用服务器中并且将 Session ID 返回到客户端存储在浏览器的 Cookie 中。 但是在分布式架构下Session 存放于某个具体的应用服务器中自然就无法满足使用了简单的可以通过 Session 复制或者 Session 粘制的方案来解决。 Session 复制依赖于应用服务器需要应用服务器有 Session 复制能力不过现在大部分应用服务器如 Tomcat、JBoss、WebSphere 等都已经提供了这个能力。 除此之外Session 复制的一大缺陷在于当节点数比较多时大量的 Session 数据复制会占用较多网络资源。Session 粘滞是通过负载均衡器将统一用户的请求都分发到固定的服务器节点上这样就保证了对某一用户而言Session 数据始终是正确的。不过这种方案依赖于负载均衡器并且只能满足水平扩展的集群场景无法满足应用分割后的分布式场景。 在微服务架构下每个微服务拆分的粒度会很细并且不只有用户和微服务打交道更多还有微服务间的调用。这个时候上述两个方案都无法满足就要求必须要将 Session 从应用服务器中剥离出来存放在外部进行集中管理。可以是数据库也可以是分布式缓存如 Memchached、Redis 等这个是常见的解决方案。 基于 Token 的认证 随着 Restful API、微服务的兴起基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同并非只是一个 key。Token 一般会包含用户的相关信息通过验证 Token 就可以完成身份校验。像 Twitter、微信、QQ、GitHub 等公有服务的 API 都是基于这种方式进行认证的一些开发框架如 OpenStack、Kubernetes 内部 API 调用也是基于 Token 的认证。基于 Token 认证的一个典型流程如下 用户输入登录信息或者调用 Token 接口传入用户信息发送到身份认证服务进行认证身份认证服务可以和服务端在一起也可以分离看微服务拆分情况了。 身份验证服务验证登录信息是否正确返回接口一般接口中会包含用户基础信息、权限范围、有效时间等信息客户端存储接口可以存储在 Session 或者数据库中。 用户将 Token 放在 HTTP 请求头中发起相关 API 调用。 被调用的微服务验证 Token 权限。 服务端返回相关资源和数据。 基于 Token 认证的好处如下 服务端无状态Token 机制在服务端不需要存储 session 信息因为 Token 自身包含了所有用户的相关信息。 性能较好因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验自然可以提升不少性能。 支持移动设备。 支持跨程序调用Cookie 是不允许垮域访问的而 Token 则不存在这个问题。 下面会重点介绍两种基于 Token 的认证方案 JWT/Oauth2.0。 JWT 介绍 JSON Web TokenJWT是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准RFC 7519。来自 JWT RFC 7519 标准化的摘要说明JSON Web Token 是一种紧凑的URL 安全的方式表示要在双方之间传输的声明。JWT 一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息以便于从资源服务器获取资源也可以增加一些额外的其它业务逻辑所必须的声明信息该 Token 也可直接被用于认证也可被加密。 JWT 认证流程 客户端调用登录接口或者获取 token 接口传入用户名密码。 服务端请求身份认证中心确认用户名密码正确。 服务端创建 JWT返回给客户端。 客户端拿到 JWT进行存储可以存储在缓存中也可以存储在数据库中如果是浏览器可以存储在 Cookie 中在后续请求中在 HTTP 请求头中加上 JWT。 服务端校验 JWT校验通过后返回相关资源和数据。 JWT 结构 JWT 是由三段信息构成的第一段为头部Header第二段为载荷Payload)第三段为签名Signature。每一段内容都是一个 JSON 对象将每一段 JSON 对象采用 BASE64 编码将编码后的内容用. 链接一起就构成了 JWT 字符串。如下 header.payload.signature 1. 头部Header 头部用于描述关于该 JWT 的最基本的信息例如其类型以及签名所用的算法等。这也可以被表示成一个 JSON 对象。 {typ: JWT,alg: HS256} 在头部指明了签名算法是 HS256 算法。 2. 载荷payload 载荷就是存放有效信息的地方。有效信息包含三个部分 标准中注册的声明 公共的声明 私有的声明 标准中注册的声明建议但不强制使用 issJWT 签发者 subJWT 所面向的用户 aud接收 JWT 的一方 expJWT 的过期时间这个过期时间必须要大于签发时间 nbf定义在什么时间之前该 JWT 都是不可用的 iatJWT 的签发时间 jtiJWT 的唯一身份标识主要用来作为一次性 token, 从而回避重放攻击。 公共的声明 公共的声明可以添加任何的信息一般添加用户的相关信息或其他业务需要的必要信息. 但不建议添加敏感信息因为该部分在客户端可解密。 私有的声明 私有声明是提供者和消费者所共同定义的声明一般不建议存放敏感信息因为 base64 是对称解密的意味着该部分信息可以归类为明文信息。 示例如下 { iss: Online JWT Builder,iat: 1416797419,exp: 1448333419,aud: www.primeton.com,sub: devopsprimeton.com,GivenName: dragon,Surname: wang,admin: true
} 3. 签名signature) 创建签名需要使用 Base64 编码后的 header 和 payload 以及一个秘钥。将 base64 加密后的 header 和 base64 加密后的 payload 使用. 连接组成的字符串通过 header 中声明的加密方式进行加盐 secret 组合加密然后就构成了 jwt 的第三部分。 比如HMACSHA256(base64UrlEncode(header) . base64UrlEncode(payload), secret) JWT 的优点 跨语言JSON 的格式保证了跨语言的支撑 基于 Token无状态 占用字节小便于传输 关于 Token 注销 Token 的注销由于 Token 不存储在服务端由客户端存储当用户注销时Token 的有效时间还没有到还是有效的。所以如何在用户注销登录时让 Token 注销是一个要关注的点。一般有如下几种方式 Token 存储在 Cookie 中这样客户端注销时自然可以清空掉 注销时将 Token 存放到分布式缓存中每次校验 Token 时区检查下该 Token 是否已注销。不过这样也就失去了快速校验 Token 的优点。 多采用短期令牌比如令牌有效期是 20 分钟这样可以一定程度上降低注销后 Token 可用性的风险。 OAuth 2.0 介绍 OAuth 的官网介绍An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications。OAuth 是一种开放的协议为桌面程序或者基于 BS 的 web 应用提供了一种简单的标准的方式去访问需要用户授权的 API 服务。OAUTH 认证授权具有以下特点 简单不管是 OAuth 服务提供者还是应用开发者都很容易于理解与使用 安全没有涉及到用户密钥等信息更安全更灵活 开放任何服务提供商都可以实现 OAuth任何软件开发商都可以使用 OAuth OAuth 2.0 是 OAuth 协议的下一版本但不向后兼容 OAuth 1.0即完全废止了 OAuth 1.0。 OAuth 2.0 关注客户端开发者的简易性。要么通过组织在资源拥有者和 HTTP 服务商之间的被批准的交互动作代表用户要么允许第三方应用代表用户获得访问的权限。同时为 Web 应用桌面应用和手机和起居室设备提供专门的认证流程。2012 年 10 月OAuth 2.0 协议正式发布为 RFC 6749。 授权流程 OAuth 2.0 的流程如下 A用户打开客户端以后客户端要求用户给予授权。B用户同意给予客户端授权。C客户端使用上一步获得的授权向认证服务器申请令牌。D认证服务器对客户端进行认证以后确认无误同意发放令牌。E客户端使用令牌向资源服务器申请获取资源。F资源服务器确认令牌无误同意向客户端开放资源。 四大角色 由授权流程图中可以看到 OAuth 2.0 有四个角色客户端、资源拥有者、资源服务器、授权服务器。 客户端客户端是代表资源所有者对资源服务器发出访问受保护资源请求的应用程序。 资源拥有者资源拥有者是对资源具有授权能力的人。 资源服务器资源所在的服务器。 授权服务器为客户端应用程序提供不同的 Token可以和资源服务器在统一服务器上也可以独立出去。 客户端的授权模式 客户端必须得到用户的授权Authorization Grant才能获得令牌access token。OAuth 2.0 定义了四种授权方式authorizationcode、implicit、resource owner password credentials、client credentials。 1. 授权码模式authorization code 授权码模式authorization code是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器与服务提供商的认证服务器进行互动。流程如下 用户访问客户端后者将前者导向认证服务器。 用户选择是否给予客户端授权。 假设用户给予授权认证服务器将用户导向客户端事先指定的重定向 URIredirection URI同时附上一个授权码。 客户端收到授权码附上早先的重定向 URI向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的对用户不可见。 认证服务器核对了授权码和重定向 URI确认无误后向客户端发送访问令牌access token和更新令牌refresh token。 2. 简化模式implicit 简化模式Implicit Grant Type不通过第三方应用程序的服务器直接在浏览器中向认证服务器申请令牌跳过了授权码这个步骤因此得名。所有步骤在浏览器中完成令牌对访问者是可见的且客户端不需要认证。流程如下 客户端将用户导向认证服务器。 用户决定是否给于客户端授权。 假设用户给予授权认证服务器将用户导向客户端指定的重定向 URI并在 URI 的 Hash 部分包含了访问令牌。 浏览器向资源服务器发出请求其中不包括上一步收到的 Hash 值。 资源服务器返回一个网页其中包含的代码可以获取 Hash 值中的令牌。 浏览器执行上一步获得的脚本提取出令牌。 浏览器将令牌发给客户端。 3. 密码模式Resource Owner Password Credentials 密码模式中用户向客户端提供自己的用户名和密码。客户端使用这些信息向服务商提供商索要授权。在这种模式中用户必须把自己的密码给客户端但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下比如客户端是操作系统的一部分或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下才能考虑使用这种模式。流程如下 用户向客户端提供用户名和密码。 客户端将用户名和密码发给认证服务器向后者请求令牌。 认证服务器确认无误后向客户端提供访问令牌。 4. 客户端模式Client Credentials 客户端模式Client Credentials Grant指客户端以自己的名义而不是以用户的名义向服务提供商进行认证。严格地说客户端模式并不属于 OAuth 框架所要解决的问题。 在这种模式中用户直接向客户端注册客户端以自己的名义要求服务提供商提供服务其实不存在授权问题。流程如下 客户端向认证服务器进行身份认证并要求一个访问令牌。 认证服务器确认无误后向客户端提供访问令牌。 思考总结 正如 David Borsos 所建议的一种方案在微服务架构下我们更倾向于将 Oauth 和 JWT 结合使用Oauth 一般用于第三方接入的场景管理对外的权限所以比较适合和 API 网关结合针对于外部的访问进行鉴权当然底层 Token 标准采用 JWT 也是可以的。JWT 更加轻巧在微服务之间进行访问鉴权已然足够并且可以避免在流转过程中和身份认证服务打交道。当然从能力实现角度来说类似于分布式 Session 在很多场景下也是完全能满足需求具体怎么去选择鉴权方案还是要结合实际的需求来。转载于:https://www.cnblogs.com/liufei1983/p/9031331.html
