API包含在所有内容中，因此管理其安全性至关重要。请继续阅读，向集成和应用程序开发专家学习。

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

让我们谈谈信任第一！

在处理安全性时，优先考虑一条规则：不要信任任何人。如果您是API提供商，则您不能相信调用API的应用程序是您期望的那个，您收到的令牌没有被盗，或者客户端和服务器之间的通信没有被截获。在客户端，您不能相信应用程序不会被反编译（暴露嵌入的秘密），应用程序存储不会通过XSS攻击受到损害，或者您的用户不会被欺骗提交伪造的请求。

这意味着您必须采取适当的措施来安全地获取，存储和管理调用后端API所需的安全令牌。

此外，如果您从未公开宣传过API，您可能认为您的API是安全的。对您而言，他们感到私密，因为它们仅供您的企业应用程序使用。但是，如果它们可以在移动应用程序中使用，则它们在公共互联网上，因此是公开的。在企业网络外部暴露的任何API都必须被视为公开的。

获取令牌的API密钥

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

在设计API的安全性方面时，您必须明智地选择API使用者如何访问它。按照通常的安全措施，诱发风险是考虑的关键因素。保护仅允许咨询天气数据的API与保护银行支付API非常不同。

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

创建OAuth是为了解决这些缺点：

访问资源的应用程序是已知的（使用客户端应用程序凭据）。API提供程序可以定义范围以限制对某些操作的访问（您可以获取目录条目，但是即使使用有效的标记，也不能输入新的目录条目）。令牌的生命周期有限。让我们从一些术语开始

OAuth术语有时会令人困惑。在下表中，我们提供了从实用的，以开发为重点的术语到OAuth术语的映射。

不透明与JWT

OAuth不强制使用访问令牌格式，因此，根据OAuth服务器实现，访问令牌可能是不透明的（通常是不带信息的长字符串）或JSON Web令牌（JWT）。

JWT的关键优势是能够包含声明或有关用户的信息，后端服务可以使用这些声明来制定业务逻辑决策。

学习OAuth舞蹈

OAuth授权类型定义客户端如何获取令牌。我们的团队通常将此称为“OAuth舞蹈”。在OAuth世界中有很多种方式可以跳舞，但只有一种方法你必须学习：授权代码。在某些情况下，其他授权类型可能很有用，但授权代码授予类型是获取所有类型应用程序的访问令牌的推荐方法：Web应用程序，本机应用程序和移动应用程序。

特别是对于公共客户端和移动应用程序，建议采取额外的安全措施来防止授权代码被盗。该安全层在Proof Key for Code Exchange标准（PKCE，发音为“pixy”）中描述。您可以在此处了解有关PKCE以及如何使用它的更多信息。如果您是API提供商，请确保您的OAuth服务器支持此选项。

您应该特别注意资源所有者密码授权：最简单的实现，它非常有吸引力。但是，由于其核心要求是客户端- 服务器信任，因此您可能永远不应该使用它。

令牌管理建议

注意OAuth应用程序凭据泄漏

在GitHub中存储您的应用程序代码？您的OAuth应用凭据是否也存储在那里，特别是客户端密钥？这是今天凭证泄密的头号来源。如果这些凭据被盗，任何人都可以伪装成你。如果您认为凭据可能已被泄露，请立即重新生成凭据。

此外，永远不要将您的客户端秘密放在分布式代码中，例如通过应用商店或客户端JavaScript下载的应用。

不要在应用程序中硬编码令牌

简化代码以获取令牌很长一段时间并将其存储在应用程序中可能很诱人。别。做。那。

像对待密码一样对待代币

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

OAuth不是身份验证协议

OAuth是关于委派对资源的访问权限。它不是身份验证协议（尽管名称）。将代币视为酒店卡。您需要对自己进行身份验证以获取酒店钥匙，但是一旦您拥有它，它绝不会证明您是谁。API提供商不得依赖令牌占有作为身份证明，正如最近的用户信息泄露所证明的那样。

你真的应该看看OpenID Connect（OIDC），一个补充规范，而不是试图在OAuth之上实现身份验证。OIDC允许用户与应用程序共享其配置文件的某些方面，而无需共享其凭据。

谨防你在JWT中存储什么以及谁有权访问它们

JWT可以以声明的形式存储大量信息，并且如果被捕获则可以轻松解析（除非它们被加密）。如果您使用JWT来传输仅对后端服务有用的信息，您可以采用不同的方法：JWT可以以声明的形式存储大量信息，并且如果被捕获则可以轻松解析（除非它们被加密）。如果您使用JWT来传输仅对后端服务有用的信息，您可以采用不同的方法：

在客户端和后端之间使用不透明字符串或基本JWT。在后端，验证请求并注入一个新的JWT，其中包含一个包含下游消耗的声明的有效负载。许多API安全网关都提供此功能。如果要在整个流中使用相同的令牌，并且它可能携带敏感信息，请加密令牌有效负载。这就是说，永远不要使用JWT来携带用户的凭据，比如密码！

彻底验证JWT

当您在服务器端收到JWT时，必须彻底验证其内容。特别是，您应该拒绝任何不符合您预期的签名算法或使用弱算法或弱非对称/对称密钥进行签名的JWT。此外，您必须验证所有声明，到期日期，发布者和受众。

某些库和工具为您执行此操作;其他人需要先正确配置;有些人只做部分检查。根据您使用的库采取适当的措施。

不要将令牌存储在本地存储中;使用安全Cookie

浏览器本地存储和会话存储可以从JavaScript读取，因此对于存储诸如令牌之类的敏感信息是不安全的。相反，使用安全cookie， httpOnly 标志和CSRF措施来防止令牌被盗。

始终通过HTTPS和请求正文传输令牌

这样做可以限制令牌在飞行中被捕获或写入代理日志或服务器日志的风险。您还应该确保只使用TLS 1.2/ 1.3以及涉及颁发和验证令牌的所有参与者的最安全的密码套件。

使用专用浏览器视图来请求同意信息

许多应用程序使用嵌入式用户代理，但应避免这种情况，因为它不允许用户正确验证他们正在与哪个站点进行通信。此外，该应用程序将完全可见用户输入的凭据。正如OAuth本机应用最佳做法标准所鼓励的那样，一些API提供商会采取强有力的措施来应对这种做法。

结论

访问令牌是实现现代应用程序的基础- 但必须小心处理。作为后端开发人员，您必须确保提供适当的授权类型以获取访问令牌，支持移动应用程序的PKCE以及彻底验证JWT。作为前端开发人员，您必须控制JWT的存储并保护应用程序凭据。