SafePloy安策-数据加密-密钥管理-加密狗软件供应商

产品发布：安策信息资深技术：安策IAM技术部受欢迎度：

集成统一身份认证系统

API无处不在，因此管理其安全性至关重要。现代应用程序（包括基于Web应用程序和本机应用程序）都依赖于后端的API来访问受保护的资源。若要授权对这些API的访问，请求必须包含某种访问令牌或密钥。本文重点介绍访问令牌管理的安全最佳实践 — 适用于API提供商和应用程序开发人员。

先谈谈信任！

在处理安全问题时，只有一条规则占上风：不信任任何人。如果你是API提供商，则不能相信调用API的应用程序是你期望的应用程序，你收到的令牌未被盗，或者客户端与服务器之间的通信未被截获。在客户端，你不能相信应用程序不会被反编译（暴露嵌入式机密），应用程序存储不会因XSS攻击而受到损害，或者你的用户不会被愚弄以提交伪造的请求。

获取令牌和API密钥

在使用API时，通常会提供两种选择：将静态信息与API调用一起传递，或者在调用 API 之前动态获取该信息。此信息通常是访问令牌或 API 密钥。由于传统原因，BasicAuth仍用于某些 API，但已作为主流解决方案弃用。

在设计API的安全性方面时，必须明智地选择API使用者访问它的方式。像往常一样，安全措施，诱导的风险是要考虑的关键因素。保护仅允许查询天气数据的API与保护银行支付API有很大不同。

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

创建OAuth是为了解决以下缺点：

访问资源的应用程序是已知的（使用客户端应用程序凭据）。

API 提供程序可以定义范围以限制对某些操作的访问（可以获取目录条目，但不能PUT新的目录条目，即使使用有效的令牌也是如此）。令牌的生存期有限。

令牌管理建议

谨防 OAuth 应用凭据泄漏：将应用程序代码存储在GitHub 中？OAuth应用凭据是否也存储在那里，尤其是客户端机密？这是当今凭据泄漏的头号来源。如果这些凭据被盗，任何人都可以假装是你。如果认为凭据可能已泄露，请立即重新生成它们。此外，切勿将客户端机密放在分布式代码中，例如通过应用商店或客户端JavaScript下载的应用。

· 不要对应用程序中的令牌进行硬编码：简化代码以长时间获取令牌并将其存储在应用程序中可能很诱人。

· 像对待密码一样对待令牌：令牌和API密钥允许拥有它们的任何人访问资源。因此，它们与密码一样重要。以同样的方式对待他们。

· OAuth不是身份验证协议：OAuth是关于委派对资源的访问权限。它不是身份验证协议（尽管名称如此）。将代币视为酒店卡，需要对自己进行身份验证才能获得酒店钥匙，但是一旦拥有它，它绝不能证明你是谁。API提供商不得依赖令牌所有权作为身份证明，正如最近的用户信息泄露所证明的那样。应该看看OpenID Connect（OIDC），一个补充规范，而不是试图在OAuth之上实现身份验证。OIDC允许用户与应用程序共享其配置文件的某些方面，而无需共享其凭据。

· 谨防在JWT中存储的内容以及谁有权访问它们：JWT可以以声明的形式存储大量信息，并且在捕获时可以轻松解析（除非它们被加密）。如果使用JWT来传输仅对后端服务有用的信息，则可以采用不同的方法：JWT 可以以声明的形式存储大量信息，并且在捕获时可以轻松解析（除非它们已加密）。

· 始终通过HTTPS和请求正文中传输令牌：这样做是为了限制令牌在传输过程中捕获或写入代理日志或服务器日志的风险。还应确保仅在发行和验证令牌所涉及的所有参与者中使用TLS 1.2 / 1.3和最安全的密码套件。

· 使用专用浏览器视图请求同意信息：许多应用程序使用嵌入式用户代理，但应避免这样做，因为它不允许用户正确验证他们正在与哪个站点通信。此外，该应用程序将完全可以查看用户输入的凭据。某些API提供商针对这种做法采取了强有力的措施，正如OAuth本机应用最佳实践标准那样。