security - 大多数开放平台上的app-id和app-key有什么区别？

Question

在大多数开放平台系统中，如 Facebook、Twitter。

客户端应用有三个值。App-Id,App-Key,App-Secret.

App-Secret 很容易理解。永远不会向公众展示的 secret 值，不得将其捆绑到客户端应用程序中以确保安全。

App-Id,App-Key都是用来区分客户端应用的。两者都可能捆绑到客户端应用程序中。

我认为 App-Id/App-Secret 对或 App-Key/App-Secret 对适用于大多数情况。

为什么大多数平台都需要App-Id和App-Key？设计目的是什么？

现在，我认为 App-Id 和 App-Key 都只是一个 ID，App-Id是一个数字id，App-Key是一个UUID。对吗？

Answer 1

TL;DR - 术语“App Id”和“App Key”的定义取决于服务提供商对授权策略的实现。通常，“App Id”表示 oAuth 客户端 ID，“App Key”表示 oAuth 客户端 secret ，但一些提供商可能将“App Id”和“App Key”定义为同一事物(客户端 id)。

全文:

条款基于 oAuth 协议(protocol)。 (某些平台使用的 OpenID Connect 是 oAuth 的超集)。您可能知道，在 oAuth 中有 3 个协作实体:客户端、授权服务器 和资源服务器。客户端代表客户端应用程序被授权。为了让授权服务器区分客户端(应用程序 A 与应用程序 B)，客户端必须向授权服务器注册。来自 RFC 6749 (oAuth 2.0):

Before initiating the protocol, the client registers with theauthorization server. The means through which the client registerswith the authorization server are beyond the scope of thisspecification but typically involve end-user interaction with an HTMLregistration form.

当客户端注册时，它会收到一个客户端ID:

The authorization server issues the registered client a clienidentifier -- a unique string representing the registrationinformation provided by the client. The client identifier is not asecret; it is exposed to the resource owner and MUST NOT be used alonefor client authentication. The client identifier is unique to theauthorization server.

此外，如果客户端类型是 secret (由规范定义为能够维护其凭据的 secret 性或能够使用其他方式进行安全客户端身份验证)，该规范要求客户端建立一种验证自身的方法:

The client and authorization server establish a client authenticationmethod suitable for the security requirements of the authorizationserver. The authorization server MAY accept any form of clientauthentication meeting its security requirements. Confidential clientsare typically issued (or establish) a set of client credentials usedfor authenticating with the authorization server (e.g., password,public/private key pair).

到目前为止，我们有两件事 - 客户端 ID 和一组可选的客户端凭据。在许多流程(授权类型)中，后者确实变成了称为客户端 secret 的单个项目，本质上是密码。

某些平台可能将客户端 ID 称为“应用程序 key ”，其他平台将其称为“消费者 ID”，还有一些平台将其称为“客户端 key ”。 Twitter 创建了这个 pithy doc note为了消除混淆:

Client Credentials:

App Key === API Key === Consumer API Key === Consumer Key === Customer Key === oauth_consumer_key

App Key Secret === API Secret Key === Consumer Secret === Consumer Key=== Customer Key

此注释非常无用。他们试图说明一个观点，即整个宇宙的实现为同一概念分配不同的标签，但他们的尝试很糟糕。 Twitter 的实现不使用 App Key Secret，他们只需要一个 App Key(客户端 ID)。在 Twitter 的流程中，App Key/client id 被称为 oauth_consumer_key。

如果您查看其他服务提供商的文档，您会得到一个更好的主意。 Facebook 在他们自己的 API 中包装了大量的 oAuth 流程，所以他们不是一个很好的例子。 Salesforce是一个更直接的实现。它将客户端 ID 称为消费者 key ，将客户端 secret 称为消费者 secret 。

总而言之，提供客户端 ID 和可选客户端密码的要求是由 oAuth 规范驱动的。如果服务提供商遵守 oAuth，则他们用于自己实现的标签应该与规范相对应。 Twitter 在其文档中应使用超过 140 个字符!