使用 OAuth 2 和 JWT 为微服务提供安全保障

Part 1 - 理论相关

做者 freewolf

关键词

微服务、Spring Cloud、OAuth 2.0、JWT、Spring Security、SSO、UAA

写在前面

做为从业了十多年的IT行业和程序的老司机，今天若是你说你不懂微服务，都很差意思说本身的作软件的。SOA喊了多年，无人不知，但又有多少系统开发真正的SOA了呢？可是好像一晚上之间全部人都投入了微服务的怀抱。

做为目前最主流的“微服务框架”，Spring Cloud发展速度很快，成为了最全面的微服务解决方案。无论什么软件体系，什么框架，安全永远是不可能绕开的话题，我也把它做为我最近一段时间研究微服务的开篇。

老话题！“如何才能在微服务体系中保证安全？”，为了达成目标，这里采用一个简单而可行方式来保护Spring Cloud中服务的安全，也就是创建统一的用户受权中心。

这里补充说一下什么是Authentication（认证）和Authorization（鉴权），其实很简单，认证关心你是谁，鉴权关心你能干什么。举个你们一致都再说的例子，若是你去机场伺机，你持有的护照表明你的身份，这是认证，你的机票就是你的权限，你能干什么。

学习微服务并非一个简单的探索过程，这不得学习不少新的知识，其实不论是按照DDD（Domain Driven Design）领域驱动设计中领域模型的方式，仍是将微服务拆分红更小的粒度。都会遇到不少新的问题和之前一直都没解决很好的问题。随着不断的思考，随着熟悉Facebook/GitHub/AWS这些机构是如何保护内部资源，答案也逐渐浮出水面。

为了高效的实现这个目标，这里采用OAuth 2和JWT(JSON Web Tokens)技术做为解决方案，

为何使用OAuth 2

尽管微服务在现代软件开发中还算一个新鲜事物，可是OAuth 2已是一个普遍使用的受权技术，它让Web开发者在本身提供服务中，用一种安全的方式直访问Google/Facebook/GitHub平台用户信息。但在我开始阐述细节以前，我将揭开聚焦到本文真正的主题：云安全

那么在云服务中对用户访问资源的控制，咱们通常都怎么作呢？然我举一些你们彷佛都用过的但又不是很完美的例子。

咱们能够设置边界服务器或者带认证功能的反向代理服务器，假设全部访问请求都发给它。经过认证后，转发给内部相应的服务器。通常在Spring MVC Security开发中几乎都会这样作的。但这并不安全，最重要的是，一旦是有人从内部攻击，你的数据毫无安全性。

其余方式:咱们为全部服务创建统一的权限数据库，并在每次请求前对用户进行鉴权，听起来某些方面的确有点愚蠢，但实际上这确实是一个可行的安全方案。

更好的方式: 用户经过受权服务来实现鉴权，把用户访问Session映射成一个Token。全部远程访问资源服务器相关的API必须提供Token。而后资源服务器访问受权服务来识别Token，得知Token属于哪一个用户，并了解经过这个Token能够访问什么资源。

这听起来是个不错的方案，对不？可是如何保证Token的安全传输？如何区分是用户访问仍是其余服务访问？这确定是咱们关心的问题。

因此上述种种问题让咱们选择使用OAuth 2，其实访问Facebook/Google的敏感数据和访问咱们本身后端受保护数据没什么区别，而且他们已经使用这样的解决方案不少年，咱们只要遵循这些方法就行了。

OAuth 2是如何工做的

若是你了解OAuth 2相关的原理，那么在部署OAuth 2是很是容易的。
让咱们描述下这样一个场景，“某App但愿得到Tom在Facebook上相关的数据”

OAuth 2 在整个流程中有四种角色:

• 资源拥有者(Resource Owner) - 这里是Tom

• 资源服务器(Resource Server) - 这里是Facebook

• 受权服务器(Authorization Server) - 这里固然仍是Facebook，由于Facebook有相关数据

• 客户端(Client) - 这里是某App

当Tom试图登陆Facebook，某App将他重定向到Facebook的受权服务器，当Tom登陆成功，而且许可本身的Email和我的信息被某App获取。这两个资源被定义成一个Scope（权限范围），一旦准许，某App的开发者就能够申请访问权限范围中定义的这两个资源。

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

Tom容许了权限请求，再次经过重定向返回某App，重定向返回时携带了一个Access Token（访问令牌），接下来某App就能够经过这个Access Token从Facebook直接获取相关的受权资源（也就是Email和我的信息），而无需从新作Tom相关的鉴权。并且每当Tom登陆了某App，均可以经过以前得到的Access Token，直接获取相关受权资源。

到目前为止，咱们如何直接将以上内容用于实际的例子中？OAuth 2十分友好，并容易部署，全部交互都是关于客户端和权限范围的。

• OAuth 2中的客户端和权限范围和咱们平时的用户和权限是否相同？

• 我须要将受权映射到权限范围中或将用户映射到客户端中？

• 为何我须要客户端？

你也许在以前在相似的企业级开发案例中尝试映射过相关的角色。这会很棘手！

任何类型的应用都提供用户登陆，登陆结果是一个Access Token，全部的以后的API调用都将这个Access Token加入HTTP请求头中，被调用服务去受权服务器验证Access Token并获取该Token可访问的权限信息。这样一来，全部服务的访问都会请求另外的服务来完成鉴权。

权限范围和角色，客户端和用户

在OAuth 2中，你能够定义哪一个应用（网站、移动客户端、桌面应用、其余）能够访问那些资源。这里只有一个尺寸，来自哪里的哪一个用户能够访问那些数据，固然也是哪一个应用或者服务能够访问那些资源。换一种说法，权限范围就是控制那些端点对客户端可见，或者用户根据他的权限来获取相关的数据。

在一个在线商店中，前端能够看作一个客户端，能够访问商品、订单和客户信息，但后端能够关于物流和合同等，另外一方面，用户能够访问一个服务但并非所有的数据，这能够是由于用户正在使用Web应用，当他不能的时候，其余用户却能够。服务之间的访问时咱们要讨论的另外一个维度。若是你熟悉数学，我能够说在OAuth 2中，客户端-权限范围关系是线性独立于用户-权限关系。

为何是JWT

OAuth 2并不关心去哪找Access Token和把它存在什么地方的，生成随机字符串并保存Token相关的数据到这些字符串中保存好。经过一个令牌端点，其余服务可能会关心这个Token是否有效，它能够经过哪些权限。这就是用户信息URL方法，受权服务器为了获取用户信息转换为资源服务器。

当咱们谈及微服务时，咱们须要找一个Token存储的方式，来保证受权服务器能够被水平扩展，尽管这是一个很复杂的任务。全部访问微服务资源的请求都在Http Header中携带Token，被访问的服务接下来再去请求受权服务器验证Token的有效性，目前这种方式，咱们须要两次或者更屡次的请求，但这是为了安全性也没什么其余办法。但扩展Token存储会很大影响咱们系统的可扩展性，这是咱们引入JWT（读jot）的缘由。

+-----------+                                     +-------------+
|           |       1-Request Authorization       |             |
|           |------------------------------------>|             |
|           |     grant_type&username&password    |             |--+
|           |                                     |Authorization|  | 2-Gen
|  Client   |                                     |Service      |  |   JWT
|           |       3-Response Authorization      |             |<-+
|           |<------------------------------------| Private Key |
|           |    access_token / refresh_token     |             |
|           |    token_type / expire_in / jti     |             |
+-----------+                                     +-------------+

简短来讲，响应一个用户请求时，将用户信息和受权范围序列化后放入一个JSON字符串，而后使用Base64进行编码，最终在受权服务器用私钥对这个字符串进行签名，获得一个JSON Web Token，咱们能够像使用Access Token同样的直接使用它，假设其余全部的资源服务器都将持有一个RSA公钥。当资源服务器接收到这个在Http Header中存有Token的请求，资源服务器就能够拿到这个Token，并验证它是否使用正确的私钥签名（是否通过受权服务器签名，也就是验签）。验签经过，反序列化后就拿到OAuth 2的验证信息。

验证服务器返回的信息能够是如下内容：

• access_token - 访问令牌，用于资源访问

• refresh_token - 当访问令牌失效，使用这个令牌从新获取访问令牌

• token_type - 令牌类型，这里是Bearer也就是基本HTTP认证

• expire_in - 过时时间

• jti - JWT ID

因为Access Token是Base64编码，反编码后就是下面的格式，标准的JWT格式。也就是Header、 Payload、Signature三部分。

{ 
  "alg":"RS256",
  "typ":"JWT"
}
{
  "exp": 1492873315,
  "user_name": "reader",
  "authorities": [
    "AURH_READ"
  ],
  "jti": "8f2d40eb-0d75-44df-a8cc-8c37320e3548",
  "client_id": "web_app",
  "scope": [
    "FOO"
  ]
}
&:lƧs)ۡ-[+
F"2"Kآ8ۓٞ:u9ٴ̯ޡ 9Q32Zƌ޿$ec{3mxJh0DF庖[!뀭N)㥔knVVĖV|夻ׄE㍫}Ŝf9>'<蕱굤Bۋеϵov虀DӨ8C4K}Emޢ    YVcaqIW&*uʝub!׏*Ť\՟-{ʖX܌WTq

使用JWT能够简单的传输Token，用RSA签名保证Token很难被伪造。Access Token字符串中包含用户信息和权限范围，咱们所需的所有信息都有了，因此不须要维护Token存储，资源服务器也没必要要求Token检查。

+-----------+                                    +-----------+
|           |       1-Request Resource           |           |
|           |----------------------------------->|           |
|           | Authorization: bearer Access Token |           |--+
|           |                                    | Resource  |  | 2-Verify
|  Client   |                                    | Service   |  |  Token
|           |       3-Response Resource          |           |<-+
|           |<-----------------------------------| Public Key|
|           |                                    |           |
+-----------+                                    +-----------+

因此，在微服务中使用OAuth 2，不会影响到总体架构的可扩展性。淡然这里还有一些问题没有涉及，例如Access Token过时后，使用Refresh Token到认证服务器从新获取Access Token等，后面会有具体的例子来展开讨论这些问题。

若是您感兴趣，后面还会有实现部分，敬请期待~

因为 http://asciiflow.com/ 流程图使用中文就没法对齐了，本文中流程图都是英文了~