保护嵌入在不受信任用户可以访问的二进制文件中的密钥没有好的方法，甚至没有一半。

有理由至少要付出最小的努力来保护自己。

在 最小 的努力量将不会生效。仅仅花了几个小时的时间，即使是 最大 的努力对熟练的反向工程师/黑客也不会有效。

如果您不希望自己的OAuth密钥被黑客入侵，请不要将其放入分发给不受信任用户的代码中。期。

我是否反应过度，或者这是桌面应用程序的真正问题（使用已知解决方案）？

这是一个真正的问题， 没有已知的（有效的）解决方案 。不是用Java，不是C＃，不是Perl，不是C，不是任何东西。认为它就像是物理定律。

您的替代方法是：

• 强制用户使用仅执行加密签名代码的受信任平台。（提示：这对于您的应用程序很可能不切实际，因为当前的PC不能以这种方式工作。如果使用正确的设备，甚至TPS都可以被入侵。）

• 将您的应用程序转换为服务，然后在您控制访问的一台或多台计算机上运行它。（提示：听起来OAuth 2.0可能会删除此要求。）

• 使用一些不需要分发永久密钥的身份验证机制。

• 让您的用户签署具有法律约束力的合同，以免对您的代码进行反向工程，并在他们违反合同时提起诉讼。找出哪个用户对您的密钥进行了窃听……（提示：这不会停止黑客行为，但是如果黑客拥有资产，这可能会允许您追回损失。）

顺便说一句，类比论证是一个聪明的修辞手法，但从逻辑上讲并不合理。关于前门上的物理锁阻止人们偷窃您的东西（某种程度上）的观察结果， 没有
说明将私有信息安全地嵌入可执行文件中的技术可行性。

并且忽略了类比论证不合理的事实，该特殊类比由于以下原因而失效。物理锁不可穿透。您前门上的锁“起作用”是因为有人必须站在您的房子前面，从马路上看到您摆弄您的锁约一分钟左右……或用大铁锤敲打它。这样做的人冒着被监视的风险，并会报警。银行金库“工作”是因为穿透它们所需的时间是几个小时，并且还有其他警报器，安全警卫等等。相比之下，黑客可能会花费数分钟，数小时甚至数天的时间来尝试破坏您的技术保护措施，而实际上被发现/发现的风险为零。