你是对的。应用程序机密应该是机密的，并且不应该通过对您的客户端代码进行逆向工程来轻松获得。
Facebook 使用 OAuth，所以我在这里所说的一切也适用于所有使用 OAuth 进行授权和身份验证的应用程序。应用程序机密向 facebook 验证您的客户。就像用户名/密码对 Web 服务的用户进行身份验证一样，移动/桌面客户端使用应用程序密钥作为服务器的凭据，以验证其“真正的”合法客户端应用程序。

如果这个邪恶的家伙获得了这些条目，那么他可以进行的最糟糕的滥用是什么？

他可以制作一个看起来就像您的客户端/应用程序的欺骗客户端并发布它。毫无戒心的用户会下载它并使用它连接到 Facebook。假应用程序仍然无法获取用户凭据（这很好），因为用户凭据的身份验证发生在 facebook 页面上。然而，用户最终在 facebook 上授权了这个假应用程序。Facebook 很乐意这样做，因为它相信提出这个秘密的人就是你。结果，伪造的应用程序获得了用户的“访问令牌”，并可以开始发表评论并执行您的真实应用程序不打算做的其他事情。
因此，简而言之，您的声誉价值在这里受到威胁。其他客户可以在 facebook上冒充您的客户。

这是一个这样的 twitter 客户端的彻底案例研究，该客户端以纯文本形式存储了消费者密钥（它们相当于应用程序机密）。

我引用了该博客中的一句话：

了解泄露的消费者密钥不会危及应用程序用户的安全非常重要。该密钥不能用于访问其他用户的帐户，因为访问单个帐户需要一个访问令牌，客户端应用程序的各个实例在授权过程中代表用户自动获得该访问令牌。

现在，您如何保护客户端机密？
如果它是一个独立的客户端（如移动应用程序），您别无选择，只能以某种形式嵌入它。不幸的是，对于专业的逆向工程师来说，它被解码只是时间问题。毕竟它在客户端的某个地方（以某种形式）。如果客户可以重新计算/重新组装它，那么逆向器也可以。

编辑：如果您的应用程序架构允许，您的服务器可以代表客户端/移动应用程序执行 OAuth 步骤。这样，密钥驻留在服务器中，它执行所有 OAuth 步骤并将 access_token 传递给您的客户端，以使用它来访问用户的 facebook 数据。此时，您所做的事情与此处描述的浏览器-Web 服务器-facebook 交互非常相似。只需将该图片中的“用户浏览器”替换为“客户端/移动应用程序”，将“您的应用程序”替换为“您的服务器”即可。

如果这是某种 Web 应用程序，这可以通过仅将密钥保留在服务器端并使用 facebook 的服务器端流程来防止应用程序机密泄露来轻松实现。

以 Facebook 为例——我不知道其他支持 OAuth 的网站——有可能使用匿名的又名应用程序访问令牌。例如，它是通过appId与连接创建的令牌。appSecret504216299598238|59d273f6dddb0a2f72e727132f4a74a4

可以从移动应用程序源获取此访问令牌，并向 Graph API 发出经过身份验证的请求。然后，即使没有用户访问令牌，Facebook 也会提供一些有关较早授权此应用程序的用户的信息。

攻击者可以通过这种方式访问​​机密用户数据（例如电子邮件）。这是一个概念证明：

此用户尚未授权该应用程序：

https://graph.facebook.com/100004668630549?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4

而这个做到了：

https://graph.facebook.com/100004619894646?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4

否则电子邮件字段不可见。结果：攻击者无需与该用户进行任何交互即可获得有关被攻击用户的敏感信息。