微服务架构的安全保障OAuth 2 和 JWT

微服务对于用户资源访问如何控制：

    用户通过授权服务来实现鉴权，把用户访问Session映射成一个Token。所有远程访问资源服务器相关的API必须提供Token。然后资源服务器访问授权服务来识别Token，得知Token属于哪个用户，并了解通过这个Token可以访问什么资源。

资源访问控制--oAuth2

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

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

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

在一个在线商店中，前端可以看做一个客户端，可以访问商品、订单和客户信息，但后端可以关于物流和合同等，另一方面，用户可以访问一个服务但并不是全部的数据，这可以是因为用户正在使用Web应用，当他不能的时候，其他用户却可以。服务之间的访问时我们要讨论的另一个维度。可以说在OAuth 2中，客户端-权限范围关系是线性独立于用户-权限关系。

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

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

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

• 授权服务器(Authorization Server) - 这里当然还是Facebook，因为Facebook有相关数据

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

Tom试图登录Facebook，某App将他重定向到Facebook的授权服务器，当Tom登录成功，并且许可自己的Email和个人信息被某App获取。这两个资源被定义成一个Scope（权限范围），一旦准许，某App的开发者就可以申请访问权限范围中定义的这两个资源。

Tom允许了权限请求，再次通过重定向返回某App，重定向返回时携带了一个Access Token（访问令牌），接下来某App就可以通过这个Access Token从Facebook直接获取相关的授权资源（也就是Email和个人信息），而无需重新做Tom相关的鉴权。而且每当Tom登录了某App，都可以通过之前获得的Access Token，直接获取相关授权资源。

+--------+                               +---------------+
|        |--(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 ---|               |
+--------+                               +---------------+

 

如何安全的存储Access Token--JWT

+-----------+                                     +-------------+
|           |       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"
  ]
}

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|
|           |                                    |           |
+-----------+                                    +-----------+

 

转载于:https://my.oschina.net/yangty2017/blog/1518542