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

典型的API客户端如批量调度系统、物联网设备程序等，通常不需要用户登录授权就可以自动运行。使用客户端凭证许可类型比较适合。

客户端凭证

上图为OAuth2.0规范标准流程图，结合此场景中，对应OAuth2.0中的角色，API客户端作为OAuth2.0的客户端、IAM则为授权服务器。

• (A) API客户端与授权服务器IAM进行身份验证并请求访问令牌。
• (B) 授权服务器IAM对API客户端进行身份验证，如果有效，颁发访问令牌。客户端存储访问令牌，在后 续的请求过程中使用。如果令牌过期或失效或需要重复此流程再次申请访问令牌。

其他说明：

1. 此类应用通常不具备与用户交互的UI，无需用户授权，具备保证客户端凭证安全的能力
2. 此类应用后端需要具备通过https访问授权服务器的能力
3. 此类应用或设备需要具备存储Access Token的能力

2.2 基于登录的客户端作为访问者，使用授权码许可

2.2.1 Web 应用

OAuth2.0 协议中提出前端单页Web应用可以用简单许可模式，但简单许可模式有些局限性，令牌到期就需要重新登录授权，不支持令牌刷新，用户体验较差。很多使用简单授权的应用为了改善用户体验会颁发一个长期的令牌几天甚至几周。

如果有条件使用授权码模式，支持刷新令牌则是一个更好的选择。对访问令牌时间较短如2分钟，刷新令牌为一次性令牌有效期略长如30分，如果存在已作废的刷新令牌换取访问令牌的请求，授权端点也能够及时发现做出相应入侵处理，如注销该用户的所有刷新令牌。在保持良好用户体验的同时还兼顾了部分安全性。

本场景以微服务架构中常见的前后端分离Web应用作为示例，前端是单页应用，网关作为Web后台是服务提供端应用功能入口，也可作为OAuth2.0的客户端，让前端Web应用能借助网关实现授权码交换。因此在微服务架构中，即便是纯前端单页应用类的Web应用，仍可以用基于网关交互的授权码模式获取访问令牌。其他非前后端分离的混合Web应用自身就是客户端，不需要借助网关交换访问令牌。

授权码

上图为OAuth2.0规范标准流程图，结合此场景对应OAuth2.0中的角色，用户是资源所有者、浏览器为用户代理、网关作为被授权的客户端、IAM则为授权服务器。

• (A) 网关通过引导浏览器开始流程授权流程，重定向到统一认证中心的登录页面。
• (B)用户输入密码登录，授权服务器验证用户身份，并确认用户是否授权网关的访问请求。
• (C)用户授权后，认证中心根据之前网关注册时提供的回调地址，引导浏览器重定向回到网关。重定向URI包含授权码
• (D)网关通过包含上一步中收到的授权码和网关自身凭证从授权服务器IAM的请求访问令牌。
• (E)授权服务器IAM对网关进行身份验证，验证授权代码，并确保接收的重定向URI与网关注册时的URI相匹配。匹配成功后，授权服务器IAM响应返回访问令牌与可选的刷新令牌给网关。

其他说明：

1. 为了前端会话保持，访问令牌由网关在响应时返回到前端，存储到前端存储空间，如Cookie、Local Storage、Session Storage等。
2. 访问令牌失效后，网关根据自己的客户端凭证+刷新令牌一起发送授权服务器，获取新的访问令牌和刷新令牌，并再返回响应中将访问令牌写入到用户浏览器的存储中。
3. 授权码模式中，用户的凭证(用户名、密码)是用户通过浏览器与授权服务交互，并不经过网关， 安全性最好。

2.2.2 移动App

个人移动设备上安装的原生App本身具备实现授权码流程的能力，不需要借助网关实现授权码流程。认证通过后网关仅负责校验访问令牌即可。

授权码

移动App实现登录重定向通常可以采用如下方式：

• 模拟web端，使用移动端浏览器与WebView
• 使用URI scheme与Intent在应用间跳转

移动端App的运行环境是不可信的，容易被恶意App入侵的风险，包含如下两种情况：

1. 重定向过程中的回调URL参数，容易被恶意App占用URL Scheme或者监听localhost端口截取。
2. 运行环境不可靠，移动App不具备安全保存客户端秘钥的能力，而使用授权码获取访问令牌时需要校验客户端秘钥。

基于上述风险和问题，移动App基于授权码获取访问令牌的流程需要进行优化解决，rfc规范中建议的实现方案是移动App授权流程采用使用带有PKCE支持的授权码模式。PKCE, 全称Proof Key for Code Exchange，即保护授权代码授权。这其实是通过一种密码学手段确保恶意第三方即使截获Authorization Code或者其他密钥，也无法向认证服务器交换Access Token。

经过PKCE改进的授权码、访问令牌交换过程示意图如下：

PKCE

上图为PKCE模式下授权码申请和交换访问令牌的过程，说明如下：

• (A) 移动App客户端创建并保存名为code_verifier的随机秘钥串，并将秘钥字符串加密转换的结果t(code_verifier)称为code_challenge，将转换后的code_challenge以及转换方法一并发送到授权服务中。
• (B) 授权服务返回授权码并记录code_challenge和转换方法t_m。
• (C) 移动App客户端收到授权码后，将授权码和code_verifier秘钥串发送到授权服务器，用以申请访问令牌。
• (D) 授权服务器根据转换方法t_m 转换code_verifier 并与步骤A中收到的code_challenge比较，如果一致则返回访问令牌，否则拒绝非法请求。

（编辑：ASP站长网）