所以在过去的几天里,我在互联网上搜索了 API 安全“最佳实践”或技术,特别是从服务器到服务器(服务器到服务器)直接访问的 API。似乎有很多不同的意见,很难将它们整合成一个可行的想法。
许多人认为,OAuth 是可行的方法。根据是否希望不使用安全套接字协议,选择分别是 OAuth 1.0A 或 OAuth 2.0。
关于 OAuth,我的理解是 OAuth 1.0A 主要关注的是请求的数字标牌,而 OAuth 2.0 依赖于底层的 HTTPS 来保证完整性。那么我可以安全地做出以下假设吗?
假设:如果使用 HTTPS,不需要使用 HMAC 或任何形式的数字签名来防止重放攻击、中间人攻击并保持完整性。
这仍然会留下授权,OAuth 通过交换的令牌进行管理。但为什么这么复杂?例如,我是否可以为所有服务器(私人消费者)提供全球唯一的用户名和秘密,以便每个“请求”都使用秘密、用户名和请求参数的一些散列进行“签名”?
据我所知,这意味着授权和身份验证。身份验证由哈希的确认来管理,并且禁止授权,因为至关重要的是,每个服务器都对自己的资源拥有相同的权限。
因此,在严格为服务器到服务器(或“两条腿”)通信设计 API 时,最好的方法是什么?简单地使用 HTTPS 是否安全,然后使用个性化的哈希对每个请求进行签名,这意味着身份验证、授权并且也不需要维护状态/会话。
我可以理解,符合标准对于编写代码以使用服务的开发人员以及一般的 Web 文化是有好处的,因此遵守 OAuth 的某些“子集”听起来很有吸引力;我只是不确定这里是否需要。