从五个方面入手，保障微服务应用安全(3)

第三方无法根据code_challenge推导出code_verifier，因为code_challenge采用了不可逆加密方式。只有移动App客户端自己才知道这两个值。因此即使恶意App截获了code_challenge和授权码，也无法换取访问令牌避免了安全问题。要实现这种移动App的PKCE授权码模式，出移动App自身外，还需要IAM的授权服务器基于标准的授权码流程扩展配合实现。

关于移动App安全认证的详细内容请参考官方规范：

• rfc8252 - OAuth 2.0 for Native Apps

(https://tools.ietf.org/html/rfc825)

• rfc7636 - Proof Key for Code Exchange by OAuth Public Clients

(https://tools.ietf.org/html/rfc7636)

2.3 高度信任的特权类客户端，可以使用资源所有者密码凭据许可

用户密码凭据

上图为OAuth2.0规范标准流程图，结合此场景中，对应OAuth2.0中的角色，用户是资源拥有者、特权应用是客户端、IAM提供授权服务器

• (A)用户提供给特权App用户名和密码。
• (B)特权App将用户凭据提交给授权服务器IAM，申请访问令牌
• (C)授权服务器IAM 验证用户的凭证，如果有效，颁发访问令牌给特权App。特权App对授权服务器颁发的访问令牌、刷新令牌进行存储和更新。

其他说明：

• 虽然是特权App，但App中不要持久化保存用户密码，仅登录时使用
• App负责保存Access Token 、Refresh Token

3. 使用API 网关作业务系统访问入口，负责验证访问令牌

访问者能够访问的接口通常是两类：身份认证API、应用功能类API。

• 身份认证类API：即登录认证相关的API。为了避免用户、客户端凭证泄漏第三方(除IAM、访问者之外为第三方)，身份认证类API或UI建议由IAM系统直接开放给访问者调用进行身份认证。
• 应用功能类API：功能实现来自服务提供者，通过网关开放给访问者。网关是访问应用API的入口。

用户登录认证由IAM授权服务器配合用户资源服务负责。认证成功后，IAM访问者颁发访问令牌。后续对应用功能的访问过程中，均须携带访问令牌以表明访问者的身份。

3.1 由网关负责客户端身份验证

网关作为业务系统的API入口，当面向外网的访问者时网关还是内外网的分界，访问令牌验证理应由网关负责，不应该将令牌验证的事情交给服务提供者。网关负责验证既能避免未经验证的请求进入内网，又能够简化服务提供端的代码，服务提供端无需处理不同类型客户端的验证。实际上好处还不只这些，在网关可以统一做流控无需应用端重复建设类似功能;系统内部调试、变更敏捷，减少了跨组织交互。

网关验证访问令牌有两种方案：网关委托认证服务验证、网关直接验证，说明如下：

• 方案一：网关委托授权服务验证，每次收到请求后，网关均将访问令牌发送到IAM认证服务进行认证，认证通过后才允许继续访问。

网关委托IAM校验令牌

1. 客户端成功认证后，使用UUID类型的访问令牌调用网关上的服务
2. 由于UUID类型令牌不包含客户端的信息，网关需要委托IAM认证服务校验令牌
3. 令牌检查合法后，将请求路由到服务提供者
4. 应用中也无法解析令牌，需要根据UUID令牌到IAM中获取用户信息

• 方案二(推荐)：网关直接验证，要求网关能识别IAM颁发的令牌，这种模式推荐用 JWT令牌，网关需要具备解析校验JWT加密的访问令牌的能力。

网关直接校验令牌

1. 客户端成功认证后，使用JWT令牌调用网关上的服务
2. 网关自己直接解密JWT令牌进行校验
3. 令牌检查合法后，将请求路由到服务提供者
4. 应用受到请求后，如果需要更多权限信息，如果可以根据Token去权限管理服务获取权限信息(非必须步骤，需要时添加)。

上述两方案中，方案一的令牌是无业务含义的身份标识字符串，每次收到请求网关都去IAM认证，对IAM认证服务的性能压力较大。方案二中IAM颁发的令牌中包含部分客户端或用户信息，使用JWT加密，IAM将验证方式或SDK提供给了负责认证的网关。对于IAM来说，减少了每次请求令牌认证带来的通信次数，减轻了IAM的压力。

推荐采用方案二实现令牌检查，需要注意的是方案二中的JWT令牌中仅包含必要的信息即可，不要放太多的角色权限信息。后续功能中需要额外的信息时，可以根据令牌再去IAM中获取。如果令牌中存放了很多的权限数据，一旦后台的授权数据发生变化，令牌中的权限数据与实际IAM的权限会存在不一致的问题，只能强制用户下线重新登录。

JWT令牌是防篡改的，但并不加密，如需要存储到浏览器存储中，建议采用JWT+JWE方式进行令牌加密。令牌中存放必要少量数据即可，避免滥用。多数服务器通常会对Http header、cookie长度做限制。

3.2 系统内部应用是否通过网关?

我的答案是不需要，否则太麻烦了。通常网关是独立团队负责，API变更发布、内部联调验证还得跨团队协调实在不可行。推荐系统内直通不走网关，系统之间访问必须走网关。要做到这一点，应用也需要实别请求来源进行客户端认证，这种认证方案没必要太复杂，应用只应该允许信任的网关和系统内部应用程序访问其服务，不允许系统外部请求绕过网关直接调用，因此，需要在网关和系统内部应用之间这个小范围内建立信任，常见方案有两种：

• 方案一，内部令牌：系统内的应用在发布接口到网关时，提供一个系统内部共享的令牌给网关和系统内所有应用，接收到请求时检查请求头中是否包含系统内信任的令牌， 如果包含可信任令牌，那么就允许访问，否则就拒绝
• 方案二，系统内保密令牌+网关证书单独认证：系统内用保密令牌交互就是方案一，只是内部令牌不共享给网关，网关用公私钥证书签名方式与域内系统建立信任，由网关生成公私钥证书，颁发公钥给各个系统，网关调用服务提供者时，请求头中带上用私钥签名的令牌，应用收到请求以后用网关发布的公钥验证其令牌。

（编辑：ASP站长网）