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

其他说明：

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比较，如果一致则返回访问令牌，否则拒绝非法请求。

（编辑：西安站长网）

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