API安全之令牌访问和秘钥防护

            API无处不在,所以管理它的安全性很重要。现代应用程序(包括基于Web的应用程序和本机应用程序)依靠后端API访问受保护的资源。如果您想授权访问这些应用程序,请求必须包括一些访问令牌或密钥。本文重点介绍了访问令牌管理的最佳安全实践适用于API提供商和应用开发者。先说信任!在处理安全问题时,只有一条规则占上风:不信任任何人。如果你是API提供商,你不能相信调用API的应用程序是你期望的应用程序,你收到的令牌没有被盗,或者客户端和服务器之间的通信没有被截获。在客户端,你不能相信应用程序不会被重新编译(暴露嵌入式秘密),应用程序存储不会被XSS攻击损坏,或者你的用户不会被忽悠提交伪造请求。

outputo-20220127-091854-950-jhmw.png

这意味着你必须采取适当的措施,安全地获得后端API所需的安全令牌。另外,如果你从来没有公开宣传过API,你可能会觉得它们是安全的。对你来说,他们觉得很私密,因为它们只是由你的企业应用程序使用的。但是,如果它们可以从移动应用程序中使用,它们就在公共互联网上,所以它们是公共的。任何在企业网络之外公开的API都必须被视为公共API。

使用API时,获取令牌和API密钥通常会提供两种选择:将静态信息与API调用一起传输,或者在调用API之前动态获取信息。这些信息通常是访问令牌或API密钥。由于传统原因,BasicAuth仍然用于某些API,但已被丢弃作为主流解决方案。在设计API安全性时,必须明智选择API用户访问它的方式。像往常一样,安全措施和诱导风险是关键因素。保护只允许查询天气数据的API与保护银行支付API有很大不同。

虽然开发者更容易使用API密钥,但它不能提供与通过双因素用户身份验证和客户端应用程序正确识别获得的访问令牌相同的安全等级。此外,API密钥不携带任何关于用户的信息,也不能用于决定允许API用户在后端级别调用哪些操作。最后,除非API提供程序,否则API密钥永远不会过期。

创建OAuth是为了解决以下缺点:访问资源的应用程序已知(使用客户端应用程序凭证)。API提供的程序可以定义范围来限制访问某些操作(可以获取目录条目,但不能使用新的目录条目,即使使用有效的令牌)。令牌的生存期有限。

分享: