【.com快译】如今，无论是基于Web的应用程序，还是各种本地原生程序，都需要通过后端API来实现资源访问保护。各种访问请求要获得API的授权，必须包含相应的访问令牌或密钥。本文将重点介绍为API提供商和应用程序开发人员管理访问令牌的各种安全最佳实践。1.安全第一原则当我们处理安全问题时，首先要考虑的原则是：没有人可以信任。如果您是API提供者，您无法保证调用API的应用程序就是您所期望的应用程序，收到的令牌没有被盗用，或者客户端与服务器之间的通信没有被拦截。尤其是在客户端，您无法确定应用程序是否未被反编译（以及暴露在应用程序中的密码）。当然，你不能确定应用程序的存储不会被跨站脚本攻击（详见https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)），更不用说保证您的用户不是在受骗状态下提交伪造的请求（详见https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)）。由此可见，您必须采取适当的措施来安全地获取、存储和管理调用后端API所需的安全令牌。此外，您可能认为只要不公开发布您的API就是安全的。您甚至可能会认为，既然API仅供您自己的企业应用程序使用，那么它们当然是私有的。众所周知，如果能在手机应用中调用，那么就是放在公网上了。换句话说，在公司网络之外公开的任何API都应被视为公开的（有关详细信息，请参阅https://www.42crunch.com/a10-owasp/）。2、获取token的APIkey在使用API??的时候，我们通常有两种选择：一种是在调用API的同时传递一段静态信息；另一种是在调用API信息之前动态获取一条信息。这条信息通常称为访问令牌或API密钥。由于一些历史问题，BasicAuth（译者注：BasicAuth认证方式是在每次请求API时只提供用户的用户名和密码）仍然被一些API使用，但实际上已经不再是主流身份验证解决方案。因此，在设计API的安全性时，必须仔细考虑API消费者将如何访问它。并且在考虑您采取的安全措施时，您需要彻底分析各种风险因素。显然，对于查询天气数据的API和银行支付类型的API，我们会采取完全不同的管控措施。虽然开发人员可以轻松实现和使用API密钥，但它不如使用访问令牌通过双因素身份验证正确识别客户端应用程序安全。此外，API密钥不包含任何有关用户的信息，因此它不能在后端级别用于确定API使用者可以进行哪些调用。此外，除非API提供者主动撤销，否则API密钥永远不会过期。针对以上缺点，OAuth应运而生，其特点如下：访问资源的应用程序是已知的（使用客户端应用程序的信任凭证）。API提供者可以通过定义范围来限制对某些操作的访问（您可以GET到目录条目，但即使使用有效令牌，您仍然不能PUT新目录条目）。令牌的生命周期有限。3.让我们从一些术语开始OAuth中使用的术语有时会令人困惑。让我们使用下表来了解一些与开发相关的关键术语。4.Opaque和JWT由于OAuth对accesstoken的格式没有限制，根据OAuth服务器的实现规则，accesstoken既可以是Opaque（通常是一个没有任何有用信息的长字符串），也可以是一个JSONWebToken（智威汤逊）。JWT的优势在于它可以包含用户的各种声明或信息，后端服务可以使用它来进行各种业务逻辑决策。5.学习“OAuth舞蹈”OAuth的授权类型决定了客户端将如何获取令牌。这在我们自己的团队中通常被称为“OAuth舞蹈”。因为虽然OAuth世界中有许多“舞蹈”，但您必须记住一个：授权代码。授权代码类型是为所有应用程序（包括Web、本机和移动应用程序）获取访问令牌的推荐方法，尽管在某些情况下其他授权类型可能有用（请参阅http://www.pingidentity.com/en/company/blog/posts/2018/securely-using-oidc-authorization-code-flow-public-client-single-page-apps.html）。特别是对于公共客户端和移动应用程序，我们建议采取额外的安全措施以防止授权码被盗。这种类型的安全层通常称为代码交换证明密钥(PKCE)标准。您可以访问以下链接：https://tools.ietf.org/html/rfc7636以了解有关PKCE及其使用方法的更多信息。如果您是API提供者，请确保您的OAuth服务器支持此选项。同时要特别注意资源所有者的密码授权。虽然它最容易实现，但您可能永远不会使用它，因为它的核心要求是在客户端和服务器之间建立信任关系。六、token管理建议1、关注OAuth应用凭证泄露会把应用代码存放在GitHub中吗？您的OAuth应用程序凭据是否会存储在那里，尤其是客户端的密钥？但是你知道吗？这已成为当今受损信任凭证的头号来源。一旦这些凭据被盗，任何人都可以伪装成您并发起中间人攻击。因此，如果您发现您的凭据可能已被泄露，请立即重新生成新凭据。另外，请不要将客户端的密码放在分布式代码中，例如：通过应用软件商店下载的各种应用程序或客户端JavaScript。2.不要在应用程序中硬编码令牌。不要为了图省事，将获取token的代码简化，长期存放在自己的应用中。3.像对待密码一样对待令牌，因为任何拥有令牌和API密钥的人都可以访问相应的资源。因此，我们需要像处理各种密码一样小心处理和保存各种令牌。4.OAuth不是身份验证协议OAuth处理资源访问委托，因此它不是身份验证协议（尽管名称如此）。我们可以将令牌视为酒店房间的钥匙。您需要验证您的身份才能获得酒店的钥匙。但是，一旦您拥有密钥，它就无法再验证您是谁。最近发生的一些用户信息泄露事件已经证明，API提供者不能简单地使用令牌作为认证的基础。另外，我建议你也可以参考OpenIDConnect（OIDC，见https://www.oauth.com/oauth2-servers/openid-connect/）了解详情。但是，它只是一个补充规范，并不是要在OAuth之上实现认证功能。OIDC允许用户与应用程序共享其配置文件中的某些信息，但不能共享其信任凭证。5.注意你在JWT中存储了什么以及谁有权访问JWT可以以各种声明的形式存储很多信息，如果捕获到这些信息，攻击者可以轻松解析具体内容（除非他们被加密了）.因此，如果想使用JWT向后端服务传递有用的信息，那么可以采用如下实现方式：客户端与后端之间，只使用Opaque字符串，或者基本的JWT。在后端，验证请求并注入新的JWT，其有效负载可以包含可在下游使用的声明。许多API安全网关“开箱即用”地提供此功能。如果要全程使用同一个token，让token携带一些敏感信息，那么就必须对token的payload进行加密。也就是说，请永远不要使用JWT来携带用户的可信凭据，例如密码！6.彻底验证JWT当您在服务器端收到JWT时，请务必彻底验证其内容。需要特别注意：对于不符合预期签名算法、使用弱签名算法、使用弱非对称/对称密钥进行签名的JWT，应直接拒绝。此外，您必须验证所有声明、到期日期、发布者和接收者。有一些库和工具可以直接为您执行此操作，有些需要您事先进行适当的配置，而另一些可能只进行部分检查。因此，使用哪种方法取决于您使用的库。7.不要在本地存储令牌，请使用安全cookie。JavaScript可以读取浏览器上的任何本地存储和会话存储。可见，以这种方式存储token等敏感信息是极其不安全的。因此，您可以使用安全cookie、带有httpOnly的标识和CSRF等措施来防止令牌被盗。8.始终通过HTTPS和请求主体传输令牌。这样，您可以限制令牌在传输过程中被捕获或写入代理日志和服务器日志的风险。您还应确保仅使用TLS版本1.2/1.3，并确保在颁发和验证令牌的每个环境中使用最安全的密码套件。9.使用专用的浏览器视图请求信息许多应用程序使用嵌入式用户代理，但由于用户无法验证与他们通信的网站的真实性，我们实际上应该避免使用这样的用户代理。表演。此外，应用程序应该完全了解用户输入的凭据。一些API提供商采取强有力的安全措施来处理此类问题，这是OAuth原生应用程序的最佳实践。7.结论访问令牌是当今各种应用程序的基础，因此我们在处理它们时必须小心。如果您是后端开发人员，则必须确保提供适当的授权类型以获取访问令牌；还应支持用于移动应用程序的PKCE；以及JWT的完整验证。而如果你是一名前端开发者，你必须能够控制JWT的存储并保护应用程序的各种信任凭证。参考PKCE(https://tools.ietf.org/html/rfc7636)JWT验证实践(https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-03)NativeapplicationBestPracticeOAuth（https://tls.mbed.org/）原标题：管理API访问令牌的安全最佳实践，作者：IsabelleMauny】
