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

Question

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

客户端应用程序有三个值。应用-Id，应用-键，应用-秘密。

应用程序-秘密很容易理解。一个永远不会向公众显示的秘密价值，不能为了安全而捆绑到客户端应用程序中。

App-Id、App-Key都用于区分客户端应用程序和其他应用程序。两者都可能捆绑到客户端应用程序中。

我认为App-Id/App-秘密对，或App/App-秘密对在大多数情况下都能正常工作。

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

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

Answer 1

TL;DR -术语"App Id“和"App Key”的定义取决于服务提供者对授权策略的实现。"App“通常意味着oAuth客户端id，而"App”则意味着oAuth客户端机密，但是一些提供者可能会将"App“和"App”定义为相同的东西(客户机id)。

完整的故事：

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

在发起协议之前，客户端向授权服务器注册。客户端向授权服务器注册的方式超出了本规范的范围，但通常涉及到最终用户与HTML注册表单的交互。

当客户端注册时，它接收到一个客户端id：

授权服务器向注册客户端发送一个clien标识符--一个表示客户端提供的注册信息的唯一字符串。客户端标识符不是秘密；它向资源所有者公开，不能单独用于客户端身份验证。客户端标识符对授权服务器是唯一的。

此外，如果客户端类型是机密的(由规范定义为能够维护其凭据的机密性或能够使用其他方式确保客户端身份验证)，则规范要求客户端建立一种验证自己的方法：

客户端和授权服务器建立适合授权服务器的安全要求的客户端身份验证方法。授权服务器可以接受满足其安全性要求的任何形式的客户端身份验证。机密客户端通常被颁发(或建立)一组客户端凭据，用于与授权服务器进行身份验证(例如，密码、公钥/私钥对)。

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

有些平台可能将客户端id称为“应用键”，另一些平台则称其为“消费者id”，而另一些平台则称其为“客户端密钥”。Twitter创建这个精巧的医生注意事项是为了消除混淆：

客户端凭据： 应用密钥=== API密钥===消费者API密钥===消费者密钥===客户密钥=== oauth_consumer_key 应用密钥秘密=== API秘密密钥===消费者密钥===消费者密钥===客户密钥

这张便条毫无帮助。他们试图说明一个观点，即宇宙中的实现为同一个概念分配了不同的标签，但他们的尝试却是糟糕的。Twitter的实现不使用App秘密，他们只需要一个App (客户端id)。在Twitter的流中，App /client id被称为oauth_consumer_key。

如果您查看其他服务提供商的文档，您将得到一个更好的想法。Facebook在自己的API中封装了很多oAuth流，所以它们不是一个很好的例子。Salesforce是一个更直接的实现。它称客户身份为消费者密钥，客户端秘密为消费者秘密。

总之，提供客户端id和可选客户端秘密的需求是由oAuth规范驱动的。如果服务提供者符合oAuth，那么它们为自己的实现使用的标签应该与规范相对应。Twitter应该在他们的文档中使用超过140个字符！

Answer 2

如果您将它与我们的基本身份验证进行比较，那么它将很容易理解。与类似，应用程序ID/客户端ID就像您的用户名/电子邮件，而应用程序秘密/客户端秘密就像密码。

因此，在OAuth2中，当请求授权代码时，您需要发送应用程序ID来唯一标识您的应用程序。在此之后，您将被要求发送应用程序机密以获取令牌。