从五个方面入手,保障微服务应用安全
|
典型的API客户端如批量调度系统、物联网设备程序等,通常不需要用户登录授权就可以自动运行。使用客户端凭证许可类型比较适合。 ![]() 客户端凭证 上图为OAuth2.0规范标准流程图,结合此场景中,对应OAuth2.0中的角色,API客户端作为OAuth2.0的客户端、IAM则为授权服务器。
其他说明:
2.2 基于登录的客户端作为访问者,使用授权码许可 2.2.1 Web 应用 OAuth2.0 协议中提出前端单页Web应用可以用简单许可模式,但简单许可模式有些局限性,令牌到期就需要重新登录授权,不支持令牌刷新,用户体验较差。很多使用简单授权的应用为了改善用户体验会颁发一个长期的令牌几天甚至几周。 如果有条件使用授权码模式,支持刷新令牌则是一个更好的选择。对访问令牌时间较短如2分钟,刷新令牌为一次性令牌有效期略长如30分,如果存在已作废的刷新令牌换取访问令牌的请求,授权端点也能够及时发现做出相应入侵处理,如注销该用户的所有刷新令牌。在保持良好用户体验的同时还兼顾了部分安全性。 本场景以微服务架构中常见的前后端分离Web应用作为示例,前端是单页应用,网关作为Web后台是服务提供端应用功能入口,也可作为OAuth2.0的客户端,让前端Web应用能借助网关实现授权码交换。因此在微服务架构中,即便是纯前端单页应用类的Web应用,仍可以用基于网关交互的授权码模式获取访问令牌。其他非前后端分离的混合Web应用自身就是客户端,不需要借助网关交换访问令牌。 ![]() 授权码 上图为OAuth2.0规范标准流程图,结合此场景对应OAuth2.0中的角色,用户是资源所有者、浏览器为用户代理、网关作为被授权的客户端、IAM则为授权服务器。
其他说明:
2.2.2 移动App 个人移动设备上安装的原生App本身具备实现授权码流程的能力,不需要借助网关实现授权码流程。认证通过后网关仅负责校验访问令牌即可。 ![]() 授权码 移动App实现登录重定向通常可以采用如下方式:
移动端App的运行环境是不可信的,容易被恶意App入侵的风险,包含如下两种情况:
基于上述风险和问题,移动App基于授权码获取访问令牌的流程需要进行优化解决,rfc规范中建议的实现方案是移动App授权流程采用使用带有PKCE支持的授权码模式。PKCE, 全称Proof Key for Code Exchange,即保护授权代码授权。这其实是通过一种密码学手段确保恶意第三方即使截获Authorization Code或者其他密钥,也无法向认证服务器交换Access Token。 经过PKCE改进的授权码、访问令牌交换过程示意图如下:
PKCE (编辑:无锡站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- windows-server-2003 – 从目录服务还原模式中降级2003 DC
- ASLR是如何保护Linux系统免受缓冲区溢出攻击的
- 微软免费工具集PowerToys上架Win11应用商店 能让用户自定义
- 不符合Win11要求设备升级会被打水印 破解方法来了
- Win10设定虚拟内存方法 Win10怎么设置虚拟内存【详解】
- Firefox 70 将引入“非活跃 CSS”,快速排查 CSS 属性
- .net – System.Windows.Forms.WebBrowser在同一窗口或同一
- 许多人不知道Edge浏览器已经发布iOS/Android版本 微软表示无
- 谁能制约云厂商滥用开源,谁来帮助开源软件作者?
- win10如何查找流氓软件源头的详细介绍





