在大多数开放平台系统中，例如Facebook，Twitter。
客户端应用程序具有三个价值。 AppId ， AppKey ， AppSecret 。
AppSecret 很容易理解。永远不会公开的秘密值，为了安全起见，请勿将其捆绑到客户端应用程序中。
AppId ， AppKey 都用于区分客户端应用程序和其他应用程序。两者都可能捆绑到客户端应用程序中。
我认为AppId / AppSecret对或AppKey / AppSecret对在大多数情况下都适用。
为什么大多数平台都需要AppId和AppKey？ 设计目的是什么？
现在，我认为AppId和AppKey都只是一个ID， AppId是数字ID，AppKey是uuid。是吗？
答案 0 :(得分：3)
TL; DR-术语“应用程序ID”和“应用程序密钥”的定义取决于服务提供商对授权策略的实施。通常，“应用程序ID”将表示oAuth客户端ID，而“应用程序密钥”将表示oAuth客户端密钥，但是某些提供程序可能会定义“应用程序ID”和“应用程序密钥”来表示同一事物（客户端ID）。
完整的故事：
这些条款基于oAuth协议。 （某些平台使用的OpenID Connect是oAuth的超集）。如您所知，在oAuth中，有3个实体进行协作：客户端，授权服务器和资源服务器。客户端代表客户端应用被授权。为了使授权服务器能够区分客户端（应用程序A与应用程序B），客户端必须在授权服务器上注册。从RFC 6749（oAuth 2.0）：
在启动协议之前，客户端向 授权服务器。客户注册的方式 与授权服务器不在此范围内 规范，但通常涉及最终用户与HTML的交互 注册表。
客户端注册时，会收到客户端ID：
授权服务器向注册客户端发出客户端 标识符-代表注册的唯一字符串 客户提供的信息。客户端标识符不是 秘密;它暴露给资源所有者，并且不能单独使用 用于客户端身份验证。客户端标识符是唯一的 授权服务器。
此外，如果客户端类型为机密（由规范定义为能够维护其凭据的机密性或能够使用其他方式进行安全的客户端身份验证），规范要求客户端建立一种对自身进行身份验证的方法：
客户端和授权服务器建立客户端身份验证 适用于授权安全要求的方法 服务器。授权服务器可以接受任何形式的客户端 验证符合其安全性要求。机密客户 通常会发布（或建立）一组使用的客户端凭据 用于通过授权服务器进行身份验证（例如，密码， 公钥/私钥对。
到目前为止，我们有两件事-客户端ID和一组可选的客户端凭据。在许多流（授权类型）中，后者确实变成了一个称为客户机密的单项，本质上是一个密码。
某些平台可能将客户端ID称为“应用程序密钥”，其他平台将其称为“消费者ID”，而其他平台则将其称为“客户端密钥”。 Twitter创建了这个pithy doc note来消除这种困惑：
客户凭证：
应用密钥=== API密钥===消费者API密钥===消费者密钥===客户密钥=== oauth_consumer_key
应用程序密钥秘密=== API秘密密钥===消费者秘密===消费者密钥 ===客户密钥
此注释非常无用。他们试图说明一种观点，即整个Universe的实现将不同的标签分配给同一概念，但是他们的尝试是一个糟糕的尝试。 Twitter的实现不使用应用程序密钥秘密，它们只需要一个应用程序密钥（客户端ID）。在Twitter的流程中，应用程序密钥/客户端ID被称为oauth_consumer_key。
如果您查看其他服务提供商的文档，将会发现更好的主意。 Facebook在自己的API中包装了很多oAuth流，因此它们不是一个很好的例子。 Salesforce是更直接的实现。它将客户端ID称为“消费者密钥”，并将客户端机密称为“消费者密钥”。
总而言之，提供客户端ID和可选客户端密钥的要求由oAuth规范驱动。如果服务提供商符合oAuth，则他们用于自己的实现的标签应与规范相对应。 Twitter应该在其文档中使用140个以上的字符！
答案 1 :(得分：0)
如果将其与我们的基本身份验证进行比较，那么它将易于理解。像 App ID / Client ID 就像您的用户名/电子邮件，而 App Secret / Client Secret 就像密码。
因此在 OAuth2 中，当请求授权代码时，您需要发送应用程序ID 来唯一标识您的应用程序。之后，系统要求您发送您的应用机密以获取令牌。