我们都习惯于为数百个在线帐户使用用户名和密码 - 但如果管理不当，使用密码可能会分散注意力，并成为潜在的安全漏洞。在 API 领域也是如此。用户名本身并没有什么问题——你需要这些。但是，如果您在没有某种凭据的情况下使用它们，该凭据允许服务验证调用者的身份，那么您肯定做错了。不幸的是，许多API提供商犯了一个危险的错误，暴露了大量数据并使整个生态系统不安全。用简单的英语来说——如果你只使用 API 密钥，你可能做错了！什么是 API 密钥？API 密钥是分配给特定程序、开发人员或用户的一段代码，每当该实体调用 API 时都会使用该代码。此密钥通常是一长串生成的字符，这些字符遵循创建它们的机构指定的一组生成规则：IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx在创建帐户或应用注册时，许多 API 提供商会向其开发人员分配 API 密钥，允许他们以类似于帐户用户名和密码的方式运行。API 密钥是唯一的，因此，许多提供商选择将这些密钥用作一种安全层，禁止任何无法为所请求的服务提供密钥的人进入和进一步的权利。尽管在这种方法中使用 API 密钥具有诱人的简单性和易用性，但安全责任的转移、缺乏精细控制以及大多数开发人员对目的和用途的误解使得仅依赖 API 密钥成为一个糟糕的决定。我们不仅需要保护 API 密钥，还需要编写强大的身份控制和访问管理功能来保护整个 API 平台。责任转移在 API 密钥流程的最常见实现中，整个系统的安全性完全取决于开发人员使用者保护其 API 密钥和维护安全性的能力。但是，这并不总是稳定的。以安德鲁·霍夫曼（Andrew Hoffman）价值2375美元的Amazon EC2错误为例，该错误涉及将API密钥推送到GitHub。由于开发人员依赖于基于云的开发工具，因此 API 密钥的意外或恶意公开暴露可能是一个真正的问题。从生成密钥的那一刻起，它就会通过具有有限加密和安全选项的连接通过网络传递给用户。一旦用户收到密钥（在许多常见实现中以纯文本形式提供），用户必须使用密码管理器保存密钥，将其写下来或保存到桌面上的文件中。API 密钥存储的另一种常用方法是设备存储，它获取生成的密钥并将其保存到请求它的设备上。使用密钥时，API 提供商必须依靠开发人员来加密其流量、保护其网络并维护其安全交易。这里存在许多漏洞：包含密钥的应用程序可以被反编译以提取密钥，或者从设备上的存储中去混淆，明文文件可能会因未经批准的使用而被盗，密码管理器容易受到安全风险的影响与任何应用程序一样。由于其相对简单，API Key 方法的最常见实现都提供了一种虚假的安全感。开发人员将密钥嵌入Github推送中，在第三方API调用中使用它们，甚至在各种服务之间共享它们，每个服务都有自己的安全警告。在如此脆弱的情况下，安全性是一个巨大的问题，但它并没有真正被API密钥提出，因为“它们是如此简单 - 用户会保证它们的安全！这是一种鲁莽的观点。API 密钥仅在与 SSL 一起使用时才是安全的，这在方法的基本实现中甚至不是必需的。其他系统，如OAuth 2，Amazon Auth等，正是出于这个原因需要使用SSL。从用户体验的角度来看，将责任从服务提供商转移到开发人员消费者也是一个疏忽的决定。缺乏精细控制有些人原谅缺乏安全感。毕竟，开发人员有责任确保实施SSL等解决方案。但是，即使您确实保证了安全性，您的问题也不止于此——API 密钥在设计上缺乏精细控制。有点讽刺的是，在API密钥与RESTful服务一起使用之前，我们为SOAP服务提供了WS-Security令牌，这些令牌使我们能够通过更细粒度的控制来执行许多事情。虽然其他解决方案可以限定范围、受众、控制和管理到最小的细节，但 API 密钥通常只提供访问权限，直到被撤销。它们不能被动态地专门控制。这并不是说 API 密钥缺乏任何控制——相对有用的读/写/读写控制在 API Key 应用程序中绝对是可能的。但是，普通 API 开发人员的需求通常需要更全面的选项。这也不是局部问题。随着越来越多的设备集成到物联网中，这种控制将变得比以往任何时候都更加重要，在开发早期阶段所做的选择在API生命周期的后期放大到巨大的比例。圆孔中的方形钉子所有这些都归结为一个事实：API 密钥从未被用作安全功能。大多数开发人员使用 API 密钥作为身份验证或授权的方法，但 API 密钥仅用于标识。API 密钥最适合两件事：识别和分析。虽然分析跟踪（特别是 API 指标）可以成就或破坏系统，但其他解决方案以功能更丰富的方式实现此功能。同样，虽然 API 密钥在识别用户方面做得很好，但其他替代方案，例如公钥加密、HoK 代币等。在提供更多安全性的同时做得更好。API 密钥的优点使用 API 密钥肯定有一些正当的理由。首先，API密钥很简单。使用单个标识符很简单，对于某些用例，这是最佳解决方案。例如，如果 API 在功能上受到特别限制，其中“读取”是唯一可能的命令，则 API 密钥可能是一个合适的解决方案。无需编辑、修改或删除，安全性就不那么重要了。其次，API 密钥可以帮助减少经过身份验证的服务中与熵相关的问题。熵 - 系统内在使用过程中不断消耗的能量或电位量 - 决定了身份验证对的数量有限。如果熵规定在限定为特定字符集和样式时只能有 6 万个唯一对，那么在遇到命名问题之前，您只能拥有 5 万个设备、用户或帐户。相反，建立具有大量可接受变量的API密钥在很大程度上解决了这个问题，将理论熵增加到更高的水平。最后，API 密钥系统内的自主性非常高。由于 API 密钥独立于命名服务器和主凭据，因此可以自主创建它们。虽然这伴随着可能的拒绝服务攻击的警告，但创建的自治对于旨在利用它的系统来说非常棒。在开发 API 时，应遵循最小特权原则 - 仅允许需要资源的人访问这些特定资源。这一原则取决于系统安全中CIA的概念——机密性、完整性和可用性。如果您的 API 不处理机密信息（例如，提供证券交易所代码的 API），不提供私有或任务关键型信息（例如新闻/RSS API），或者要求持续可用性（换句话说，可以间歇性运行），则 API 密钥可能就足够了。此外，API 密钥是特定于开发人员的 API 用途的不错选择。当开发人员在操作时配置 API 客户端，并对不同的服务使用更改密钥时，这是可以接受的。回到现实在一般用例场景中，使用上述 API 密钥的好处仍然很微弱。虽然API密钥很简单，但“只读”的限制阻碍而不是解放。尽管它们提供了更高水平的熵，但此解决方案不仅限于 API 密钥，也是其他身份验证/授权解决方案所固有的。同样，可以通过创新的服务器管理和现代委派系统来实现自治。结论：API 密钥不是一个完整的解决方案当最终用户（而不是开发人员）开始使用这些密钥进行 API 调用时，API 密钥的巨大问题就会出现，这通常会使您的 API 面临安全和管理风险。归根结底，API密钥本质上不是一个完整的解决方案。虽然它们对于只读目的来说可能完全没问题，但它们的解决方案太弱，无法匹配高使用率 API 系统的复杂性。每当您开始集成其他功能（如编写、修改、删除等）时，您都必须进入识别、身份验证和授权领域。基本 API 密钥实现不支持没有额外代码或服务的身份验证，它不支持没有匹配的第三方系统或辅助应用程序的身份验证，并且它不支持在没有一些严重“黑客”的情况下扩展使用超出其最初目的的授权。虽然可以提出扩展API Keys方法以更好地支持这些解决方案的论点，但该论点将主张重新发明轮子。已经有这么多改进的解决方案可用，向 API 密钥系统添加功能没有意义。即使您确实使用Shibboleth，OpenID等向系统添加了诸如身份验证之类的东西，尤其是联合身份验证，也有很多系统已经支持此功能。API 开发最重要的方面之一是创建完整、有效的安全解决方案。决定用于保护信息的技术和方法是迄今为止API开发生命周期中最重要的一步，因为在这一领域的一个失误可能会导致毁灭性的安全漏洞。参考：Kristopher}