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

典型的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响应返回访问令牌与可选的刷新令牌给网关。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!