一文揭秘微服务架构统一安全认证设计与实践！

作者：mars

链接：https://juejin.cn/post/6906149001520037902

-     前言     -

当企业应用系统逐渐增多后，每个系统单独管理各自的用户数据容易形成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。

企业的互联网业务发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，因为它是企业互联网云平台的重要基础设施，能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供必要条件。

- 名词定义 -

• Third-party application：第三方应用程序，本文中又称"客户端"（client）。

• HTTP service：HTTP服务提供商，本文中简称"服务提供商"。

• Resource Owner：资源所有者，本文中又称"用户"（user）,即登录用户。

• User Agent：用户代理，本文中就是指浏览器。

• Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。

• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

- 研发背景 -

单体应用体系下，应用是一个整体，一般针对所有的请求都会进行权限校验。请求一般会通过一个权限的拦截器进行权限的校验，在登录时将用户信息缓存到 session 中，后续访问则从缓存中获取用户信息。

随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。

基于 Token 认证的优势如下：

• 服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。

• 性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。

• 支持移动设备,支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。

- 研发目标 -

通过标准安全认证流程，异构系统或跨服务间能够灵活地实现指定功能部件或服务的集成、统一的安全认证。

基于 Token 认证的一个典型流程如下：

1. 用户输入登录信息（或者调用 Token 接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。

2. 身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在 Session 或者数据库中。

3. 客户端将 Token 放在 HTTP 请求头中，发起相关 API 调用。

4. 被调用的微服务，验证 Token 权限。

5. 服务端返回相关资源和数据。

1、安全认证功能点

（1）获取凭证, 第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取Access Token资源访问凭证。

（2）登录授权，客户端携带Access Token凭证访问服务器资源，资源服务器验证Token、第三方应用凭证信息、资源所有者User合法性，通过Token读取资源所有者身份信息(user) 加载资源所有者的权限项执行登录。

（3）访问鉴权，第三方应用客户端访问服务端资源，系统验证访问者Access Token合法性、权限信息，验证凭证（Access Token）正确，此时资源服务器就会返回资源信息。

（4）凭证续约，Access token访问凭证过期需要进行凭证续约，刷新Token凭证有效期。

2、技术选型分析

1. 系统授权采用OAuth2开放式授权标准密码模式。

2. Token采用JWT标准。

（1）OAuth开放授权

OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息。

主要的四种授权方式：

• 授权码模式（authorization code）用在客户端与服务端应用之间授权码。

• 简化模式（implicit）用在移动app或者web app(这些app是在用户的设备上的，如在手机上调起微信来进行认证授权)。不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

• 密码模式（resource owner password credentials）应用直接都是受信任的(都是由一家公司开发的)密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。

• 客户端模式（client credentials）用在应用API访问客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

（2）Json web token (JWT)

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

3、认证流程逻辑

（1）系统授权

第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取Access Token资源访问凭证。

系统授权颁发给客户应用Access Token：

（2）系统鉴权

客户端携带Access Token凭证访问服务器资源，资源服务器验证Token、第三方应用、资源所有者User合法性，通过Token读取资源所有者身份信息(user) 加载资源所有者的权限执行登录。

系统验证访问者Access Token合法性、权限信息，验证凭证（Access Token）正确，此时资源服务器就会返回资源信息。

（3）凭证续约

Access token访问凭证过期需要进行凭证续约，刷新Token凭证有效期。

- 接口设计 -

1. 授权凭证

获取授权凭证，校验客户端身份信息、校验资源所有者身份信息，下发Token凭证。

客户端编码/安全码需要第三方应用到系统注册审核通过后生成。

2. 授权凭证续约

获取续约授权凭证，校验客户端身份信息、校验RefreshToken凭证，下发Token凭证。