微服务安全体系学习(一)

微服务框架基础学习-微服务安全(一)

学习概览

• 1.课程特点
• 2.微服务安全架构需要解决的问题
• 3.OAuth2原理和定义
• 4.典型 OAuth Flow和选型

一、课程特点

• 是微服务架构体系的第一个模块
• OAuth2协议深度剖析
• 结合案例和实操（Spring Security OAuth2)
• 结合开源项目
• 面向原理和架构
• 面向微服务

课程参考书

• OAuth2 inAction
  对OAuth2整个协议框架的细节进行了深入的分析，也讲述了如何通过简单的方式来实现OAuth2服务器，适合用于对OAuth2的原理进行深度学习，偏向于原理
• OAuth 2.0 Cookbook
  主要讲解怎样去使用用Spring Security OAuth2，偏向于实践

课程架构预览

• OAuth2授权中心架构和实践
• 微服务配置中心Apollo架构和实践
• 调用链接监控CAT架构和实践
• 微服务网关Zuul架构和实践
• 容错限流Hystrix/Turbine架构和实践
• 微服务注册发现Eureka/Ribbon架构和实践
• 时间序列监控KairosDB架构和实践
• 微服务监控告警ZMon架构和实践
• 综合案例分析

架构和技术栈预览

小课总结
此小节开明点题介绍了此模块需要学习的内容以及整个微服务框架模块概要。

二、微服务安全架构需要解决的问题

开放系统间授权问题

假设现在有第三方应用云冲印服务可以使用户访问存储在云存储服务器中的图片将其读取出来。但只有得到用户授权之后受保护的云存储服务才会让云冲印服务读取图片。那么如何让云冲印服务获取用户的权限呢? 有如下方法解决。

方法1：密码用户名复制办法

资源拥有者将自己的用户名密码复制给第三方应用，然后第三方应用去访问受保护的资源，此方法适用于传统的公司内部开发，在开放系统间这样做十分的不安全。

方法2：万能钥匙

客户应用和受保护资源之间商议一个通用的developer key，用户在受保护资源得到一个developer key交给第三方应用，第三方应用在通过这个developer key去访问受保护的资源。这种关系的缺点是需要客户应用和受保护资源之间存在信任关系的情况，对于不受信的第三方应用来说是不合适的。

方法3：特殊令牌

使用一个和特殊令牌，他只能访问受保护的资源，此方法比上面两种方法可靠的多，与OAuth2的做法十分接近。

传统单块应用安全

传统单块应用的构架中，通常我们的单块应用会部署到应用服务器做成集群，其中会有一个专门用于处理登录授权的用户数据库。当用户访问应用服务器时，会通过应用的过滤器进行拦截，如果没有登录的话会先到用户数据库中鉴权登录，如果通过了服务器会发给客户端一个Session ID，客户端将Session ID保存在Cookie中。

现代微服务安全

对于现代微服务构架而言，上面的做法就不适用了，因为服务之间拆分粒度较小，需要考虑服务和服务之间的认证和鉴权，还有就是应用形态变得多种多样，这种情况下会设计成单独的内部微服务，将认证和授权做成一个单独AuthServer，通过Token的形式进行鉴权和授权。

小课总结

1.开放系统间授权

社交联合登录开放：此场景在需要第三方的应用账号登录的案例时出现，例如我们登录美团时可以使用微信去认证登录。
API平台：微信不仅可以用微信账号去操作微信小程序，还可以使用微信API来操作微信小程序。

2.现代微服务安全

现代微服务中有许多客户端需要接入例如：单页浏览器、 App(HTML5/JS/无状态)、无线原生App、服务器WebApp、微服务和API间调用等等一系列客户端之间接入需要安全保证，这种情况下需要将认证和授权做成一个单独的服务，以令牌的形式进行授权和鉴权。

3.企业内部应用认证授权(IAM/SSO)

企业内部应用繁多，例如代码平台、应用发布平台、OA 系统等。如果为这些系统分别都创建一个账户，那么这对用户来说将是一个灾难，我们要记住每个账户和密码，每个系统都需要分别登录。因此有点规模的企业都需要一套单点登录的服务，我们可以通过 OAuth 2来实现企业级的 SSO（单点登录） 服务。

三、OAuth2的原理和定义

OAuth2的原理

OAuth2的最简向导清楚的告诉了我们，客户应用请求资源服务器访问用户数据，在没有OAuth2的情况下，资源服务器区分不出请求过来的用户是恶意用户还是其他用户，数据都会返回。有了OAuth2之后，使用授权服务器颁发给客户应用Access Token，资源服务器拿到Access Token进行校验，校验通过之后才返回数据。

整体流程为：

客户应用向授权服务器请求Access Token–> 授权服务器向用户征询意见，是否将授权给客户应用–> 用户同意–>授权服务器生成颁发Access Token给客户应用–>客户应用请求资源服务器–>资源服务器验证客户应用的Access Token -->验证通过，返回数据。

OAuth2的定义

OAuth 2.0的历史

什么是OAuth2.0？

  1.OAuth2是用于REST/APIs的代理授权框架
  2.基于令牌Token的授权，在无需暴露用户密码的情况下，使应用能获取对用户数据的有限访问权限。
  3.解耦认证和授权
  4.标准安全框架，支持多种用例场景  
         * 服务器端WebAPP
         *浏览器单页SAP
         *无线/原生APP
         *服务器对服务器之间

令牌比仆从钥匙（Valet Key）

给应用授予有限的访问权限，让应用能够代表用户去访问用户的数据。

OAuth2.0的优缺点

优点：

• OAuth2.0比OAuth1.0易于实现
• 更安全客户端不接触用户密码，服务端更易于集中保护
• 广泛传播并被持续使用
• 短寿命和封装的ToKen
• 资源服务器和授权服务器解耦
• 集中式授权，简化客户端
• HTTP/JSON友好，易于请求和传递token
• 考虑多种客户端架构场景
• 客户可以具有不同的信任级别

缺点：

• 协议框架太宽泛，造成各种实现的兼容性和相互操作性差
• 和OAuth1.0不兼容
• OAuth2.0不是一个认证协议（是授权协议），OAuth2.0本身并不能告诉你任何用户信息。

OAuth2.0主要的角色

• 资源拥有者（RO）: 资源的拥有人，想要分享某些资源给第三方应用
• 客户应用：通常一个Web或者无线应用，需要访问用户的受保护资源
• 资源服务器：Web站点或者Web service API，用户的受保护数据存在此处
• 授权服务器：客户应用成功认证并获得授权之后，向客户应用颁发访问令牌Access Token
  

OAuth术语

• 客户凭证：客户的clientId和密码用于凭证
• 令牌：授权服务器在接收到客户请求后，颁发访问令牌
• 作用域：客户请求访问令牌时，由资源拥有者额外指定的细分权限

OAuth2的令牌类型

• 访问令牌：用于代表一个用户或服务直接去访问受保护的资源
• 刷新令牌：用于去授权服务器获取一个新的访问令牌
• 授权码：仅用于授权码，用于交换获取访问令牌和刷新令牌
• Bearer Token：不管谁拿到Token都可以访问资源
• Proof of Possession(POP) Token：可以校验client是否对Token有明确的拥有权

主要使用访问令牌

Outh2.0的误解

• OAuth并没有支持HTTP以外的协议
• OAuth并不是一个认证协议
• OAuth并没有定义授权处理机制
• OAuth并没有定义Token格式
• OAuth2.0并没有定义加密方式
• OAuth2.0并不是一个单个协议
• OAuth2.0仅是授权框架，仅用于授权代理

小课总结

OAuth的本质就是如何获取token和如何使用token.
OAuth是一种在系统间的代理授权协议(delegation authorization)
OAuth提供一个宽泛的协议框架,具体安全场景需要定制
OAuth使用代理协议的方式解决密码共享反模式问题

四、OAuth2.0的典型模型和选型

OAuth2.0的四大典型模型

1.授权码模式

授权码模式实现流程：

• 第一步：用户访问页面将会请求重定向到授权服务器(会带过来客户标识以及获取相关信息重定向的url)。
• 第二步：授权服务器会要求用户进行认证，等待用户授权。
• 第三步：用户认证通过，授权服务器会生成一个code(授权码)发送给应用服务器，然后应用服务器拿到code并通过后端一些渠道发送给授权服务器去校验。
• 第四步：授权服务器校验通过会生成Access Token和任选的Refresh Token返回到应用服务器。
• 第五步：客户端使用Access Token直接访问真正资源。

2.简化模式

简化模式实现流程：

• 第一步：用户访问浏览器会将请求重定向到认证服务器(带上客户标识以及重定向的url)。
• 第二步：用户认证同意授权。
• 第三步：授权服务器通过重定向url返回一个Access Token给浏览器。
• 第四步：浏览器拿到Access Token还不能使用需要到后台客户资源获取一个脚本，用脚本去解析第三步获得Access Token。
• 第五步：客户端使用已解析好的Access Token访问真正资源。

3.密码模式

密码模式实现流程：

• 第一步：用户向客户端直接提供用户名和密码。
• 第二步：客户端获得用户名和密码之后会直接重定向发送给授权服务器校验。
• 第三步：授权服务器校验通过之后直接返回Access Token。
• 第四步：客户端使用Access Token直接访问真正资源。

4.客户端

客户端实现流程：

• 第一步：客户端直接向资源服务器进行身份认证，要求返回一个Access Token。
• 第二步：授权服务器通过验证后，返回一个Access Token。
• 第三步：客户端使用Access Token直接访问真正资源。

刷新令牌

如果客户端的访问令牌已经过期，刷新令牌可以简化授权流程不需要每次都去走一遍流程，快速获取新的令牌。

OAuth2.0的选型

授权流程渠道

授权流程渠道可以分为两个渠道：前段渠道和后端渠道
前段渠道：资源拥有者、客户应用和授权服务器之间的发送交互可以划分为前段渠道。
后端渠道：资源拥有者、客户应用和资源服务器之间发生的交互可以划分为后端渠道。

客户应用类型

客户应用类型可以分为两类：公开(客户标识)和私密(客户凭证)。
公开应用：主要是指单页应用SPA和原生APP应用，这类开发完是驻在客户端，客户可以直接接触这些应用的。
私密引用：主要是指Web服端应用，服务/API(机器对机器)，这种是在后端运行的，整体是相对安全的。

小课总结

OAuth2一共有四种授权模式：授权码模式、简化模式、用户名和密码模式、客户端模式。
四种授权模式的特点为：

• 授权码模式
  1.通过前端渠道客户获取授权码。
  2.通过后端渠道，客户使用授权码去交换访问令牌和刷新令牌。
  3.假定资源拥有者和客户在不同设备上。
  4.最安全的流程，因为令牌不传递经过的user-agent。
• 简化模式
  1.适用于公开的的浏览器单页应用。
  2.访问令牌直接从授权服务器返回（只有前端渠道）。
  3.不支持刷新令牌。
  4.假定资源所有者和公开应用在同一个应用上。
  5.最容易受到安全攻击
• 用户名和密码模式
  1.使用用户名和密码登录的应用，例如桌面APP，内部软件。
  2.使用用户名/密码作为授权方式从授权服务器上获取访问令牌。
  3.一般不支持刷新令牌。
  4.假定资源拥有者和公开用户在相同设备上。
• 客户端模式
  1.适用于服务器间通信厂家，机密客户代表自己或者一个用户。
  2.只有后端渠道，使用客户凭证获取一个访问令牌。
  3.因为客户凭证可以使用对称或非对称加密，该方法支持共享密码或者证书。
  根据上面四种模式的特点来进行选型，在选型时可以参考下面的流程图的思路：
  

本次课程总结

• 从上面的课程中了解开放间系统授权实现的三种简单方法，并对传统单块应用安全和现代微服务安全两种不同的系统架构的安全做法进行了比较描述。
• 从OAuth2的最简向导中我总体的理解是认证授权的，其中常出现的场景就是第三方认证和微服务认证，基于令牌的授权没在无需暴露用户密码的情况下，能使应用获取对用户数据的有限访问权限。
• OAuth2一般有四种典型模型分别为授权码模式、简化模式、用户名密码模式、客户端模式，它们根据不同的场景去使用例如是我们自己的原生App和单页应用SPA我们可以使用授权码的模式去做，但如果是第三方的应用我们就会选择使用简化模式。
• 以上总结了做授权时我们需要对外开放的系统需注意密码安全保护，对内部系统我们可以做简易验证，什么时候的开发技术都需要根据我们所需求的业务来选型。

下一篇文章地址：微服务安全体系学习(二）