如何有效地使用API​​密钥和令牌方案来保护REST API？

Question

我知道这个问题已经被问过很多次，形状和形式各不相同，但我还不清楚一些事情。令人困惑的是，围绕Web的这个主题的资源如何引用＆＃34; user＆＃34;没有明确的背景。 API密钥是为用户发布的，访问令牌也是如此，但我不认为API密钥用户与访问令牌用户相同。

• 您是否需要为最终用户客户端的不同实例使用不同的API密钥？例如，如果我为第三方API构建移动应用程序，每个实例是否都保留自己的API密钥？我不认为他们这样做，但我如何绑定API密钥，并一起访问令牌以表示某个请求来自已知用户授权的应用程序的特定实例？如果我是auth提供者，我是否必须跟踪每个提供者？
• API密钥和访问令牌通常由一对公钥和共享密钥表示。作为服务提供者（服务器端），我使用哪一个来验证我收到的消息，API密钥或访问令牌？如果我理解正确的话，那就是每个请求都应附带一个从API密钥的秘密部分派生的签名，以便服务器可以检查它是否来自可信客户端。现在我对访问令牌秘密有什么用处？我知道访问令牌用于验证系统用户是否授权应用程序代表他们进行操作，但是消息的哪一部分对访问令牌秘密有用？
• 是否从（安全的）随机数生成的哈希值和时间戳盐是一个很好的API密钥生成策略？
• 是否有（最好是开源的，基于Java的）框架来完成大部分工作？

Answer 1

让我尝试尽可能多地回答您的问题。

Apikey与访问令牌的使用

• 首先，每个用户不使用apikeys。每个分配Apikeys 应用程序（开发人员）。服务开发人员注册他们的应用程序并获得一个 一对钥匙。
• 另一方面，每个人都会获得访问令牌 使用环境中的最终用户（例外是Client Credential 授予）。
• 服务提供商可以从中识别应用程序 apikey在使用中。
• 服务提供商可以识别最终用户 访问令牌属性。
• 您应该拥有任何最终用户API，即具有关联的最终用户资源（数据或上下文）的API，由3条腿的Oauth保护。因此访问令牌对于访问这些资源是必要的。
• 仅限开发人员的资源可以通过apikey或两条腿的Oauth进行保护。这里我指的是Oauth2标准。
• 当不支持HTTPS时，首选Oauth1。这样，共享密钥不会通过不受保护的通道发送。相反，它用于生成签名。我强烈建议通过HTTPs使用Oauth2，并避免使用Oauth1以方便使用。您和您的API消费者会发现Oauth2更易于实现和使用。除非您有特定理由使用Oauth v1

作为服务提供商，您可以使用提供Oauth 1和2的Apigee Edge平台。它不是开源的。但是，您可以免费使用它，直到您需要一些高TPS或更高的SLA。