使用指定的客户端密钥设计API

Question

我正在设计一个JSON Web API，并希望通过唯一ID来区分客户端，以便监控使用情况并阻止恶意/行为不端的客户端。 API不是封装在JavaScript库中，也不是Web应用程序独有的，任何客户端类型都可以使用它（桌面，电话等）。

问题是，Web应用程序（官方网站）也是API本身的客户端 ，因此必须公开其API密钥。 因此，某些用户可以从页面上的JavaScript中提取密钥并使用它，而不是生成自己的密钥。

是否有可能以某种更好/更聪明的设计选择来某种方式缓解这个问题，或者我是否必须忍受这样一个事实：任何恶意使用API​​的人都可以利用这个？

我可以100％控制前端应用程序（EmberJS）和后端服务器（Go），因此可以建议任何更改。

• 我正在使用每个会话/ ip的速率限制为该情况添加额外的保护层
• twitter.com页面曾经也是自己API的客户端。 他们是如何解决的？

注意：问题不在于身份验证或安全性本身，而是如何要求第三方用户另外使用API​​密钥（！）进行身份验证！

Answer 1

您应该区分Web和非Web客户端。 Web的访问密钥不能在非Web中使用，反之亦然。 对于Web客户端，您可以进行引用检查等。您还可以为应用程序动态创建访问密钥，并每天（或每个会话）自动更改它们。 您还可以仅为您的应用添加一些特殊验证，例如由混淆的JS计算的一些额外密钥。

没有什么能阻止恶意用户模仿浏览器，执行JS，操纵它，然后做坏事 - 但是你可以让它烦人，以至于他们认为不值得他们付出努力。 显然需要在服务器端检查权限等非常重要的事情，因此滥用您的API不应该是一个大问题。 您必须通过网站的API密钥处理API滥用行为，与常规网络应用滥用行为相同 - IP阻止等。

您仍然需要保密非Web客户端的API密钥。 这只能通过混淆不可靠地完成，您可以将其留在客户端开发人员手中。 如果他们的密钥被泄露和滥用，你撤销它，他们将有动力解决它。

看看OAuth 2.0 ，它们会阻止许多可能对您有用的功能。 即使你不想使用它，你也可以从中获得灵感。 OpenStreetMap使用OAuth（不确定是1还是2）作为基于flash的编辑器; 只要登录用户从同一来源调用，OAuth权限授予就会自动完成。 对于第三方应用，用户需要手动执行此操作。 您可能想要检查出来。

Answer 2

只使用一个API密钥，您将无法保证API的安全。 您描述的API密钥基本上是一个公钥，您需要某种类型的私钥来进行安全识别/身份验证，并提供一种机制来提供它。

你问过Twitter是如何解决这个问题的。 他们使用Oath 1.0a。 以下是关于它如何与Twitter Developer FAQ中的API密钥相关联的简要说明。

大多数与API的集成将要求您通过API密钥向Twitter标识您的应用程序。 在Twitter平台上，术语“API密钥”通常指的是所谓的OAuth使用者密钥。 此字符串在向API发出请求时标识您的应用程序。 在OAuth 1.0a中，您的“API密钥”可能指的是此消费者密钥和“消费者密钥”的组合，这是一个用于安全地“签署”您对Twitter的请求的字符串。 除了应用程序上下文之外，对Twitter的大多数请求都需要用户上下文。 通过使用称为“访问令牌”的另一种令牌/密钥来呈现用户上下文。 有关更多信息，请参阅获取访问令牌。

您可以在Apigee.com上找到很多有关设计API的优秀资源。 他们建议使用OAuth 2.0进行身份验证/授权。

以下是如何使用HMAC身份验证来保护Web API的说明 。

当我不得不使用仅使用API​​密钥的API时，我已经为我的Web应用程序使用了一种解决方法。 我不直接从Web应用程序的客户端部分访问API（即Web浏览器中的JavaScript）。 相反，我访问API服务器端并将加密的API密钥存储在安全配置文件中。 我提供了原始API的Facade，并使用我自己的安全方法来保护依赖于应用程序类型的Facade API。

Answer 3

一般API工作流程：

1. 客户端发送请求
2. 请求已通过身份验证和授权
3. 数据被发回

网站 - 登录

1. 用户登录提供用户名和密码
2. 创建一个秘密并存储到一个coockie中

网站 - API访问

1. 客户端发送请求
2. 请求根据coockie的秘密进行身份验证和授权（随请求发送coockies）
3. 数据被发回

非WEB客户端 - 获取API KEY（长随机字母数字字符串）

1. 选项1 - 用户在网站上注册客户端，获取API KEY并将其存储到客户端
2. 选项2 - 用户输入用户名和密码到客户端，客户端使用usenamer和密码请求API KEY，返回密钥并存储到客户端。 用户名和密码不存储在客户端上。

非WEB客户端 - API通信

1. 客户端使用API​​ KEY发送请求
2. 请求已根据API-KEY进行身份验证和授权
3. 数据被发回

当使用选项2生成密钥时，您可以获得一些额外的数据，因为它来自客户端（操作系统，浏览器）。 在这种情况下，当检查API-KEY时，如果他更改了操作系统或浏览器，则可以强制用户生成新的API

关键是您的API以两种方式验证请求。 使用coockie的秘密或API KEY。 因此，无需在网站上公开API-KEY。

请注意，对于使用API​​-KEY的客户端，不涉及任何会话。 每个请求仅通过API-KEY进行身份验证。 所以这些客户端被认为是非WEB应用程序。