如何存储开放源代码桌面Twitter客户端的OAuth v1使用者密钥和机密，而不向用户透露？

我想制作一个胖客户端，桌面，开源Twitter客户端。我碰巧正在使用.NET作为我的语言，并使用Twitterizer作为我的OAuth / Twitter包装，并且我的应用程序很可能会以开源形式发布。

要获得OAuth令牌，需要四项信息：

1. 访问令牌（Twitter用户名）
2. 访问机密（Twitter密码）
3. 消费者密钥
4. 消费者的秘密

后两个信息不应该共享，例如PGP私钥。但是，由于OAuth授权流程的设计方式，这些必须位于本机应用程序上。即使该应用程序不是开源的，并且用户密钥/秘密已加密，一个熟练的用户也可以访问用户密钥/秘密对。

所以我的问题是，如何解决这个问题？桌面Twitter客户端保护其用户密钥和机密的正确策略是什么？

我找到了一个答案，该答案与我考虑使用hueniverse时所走的路径相似。超越OAuth Web重定向流程的文章提供了一些建议，其中之一是代理令牌交换过程的Web URL。我必须找到一种方法来正确地验证我的应用程序是否正在请求对此代理页面进行验证。但是，这是可能的。

我可能是错的，但是如果您将密钥与桌面或移动应用捆绑在一起（无论是否为开源），都可以访问它们。如果像Twitter和Tumblr这样的服务迫使我们使用仅OAuth API，我们有两种选择：

• 为每个应用程序设置身份验证代理服务
• 将密钥与应用程序捆绑

前者更加困难且成本更高，对于小型和开源应用程序而言不一定可以维护。后者意味着一旦垃圾邮件发送者窃取了密钥，该应用程序可能就会被阻止。由于Twitter和Tumblr尚未提供更好的选择，并且拧紧了所有台式机客户端（包括开源客户端），因此建议分发“ Big Fish”密钥，并将其用作备用。

最后，有一个选项可以强迫每个用户获取API密钥。

定义OAuth 1 的RFC 5849的4.6节指出，尽管Twitter实际使用了消费者机密，但绝不打算将其用于台式机消费者。正如Nelson Elhage在“ 尊敬的Twitter ”中指出的那样，Twitter可以并且确实会终止桌面客户端的使用者密钥，前提是该客户端的体积不会太大而导致失败。但是，有两种解决方法可以在桌面或移动应用程序中使用OAuth 1。

一种方法是通过您所操作的服务器代理整个Twitter协议。这样，消费者机密信息将保留在您的服务器上。这是OAuth 1规范的编辑者Dick Hardt建议的解决方法。此解决方法不能解决操作此服务器的成本。

Raffi Krikorian在Twitter开发讨论会Google组上的帖子和Chris Steipp在Wikipedia邮件列表上的帖子中建议的另一种方法是“让每个用户将自己的桌面应用程序副本注册为自己的使用者”。然后，用户将复制新注册的用户密钥和用户密钥并将其粘贴到您的应用程序中。然后，您的应用程序手册将需要包括有关如何在Twitter开发人员网站上注册新应用程序的详细说明。此官方限制有一些实际问题：

• 与知名的专有客户端相比，您的客户端将面临可用性方面的劣势。
• 创建新应用的表单似乎无法提供一种预填充必填字段的方法。这意味着每当Twitter更改注册应用程序的过程时，您将必须在手册中更新注册演练。
• 开发人员协议要求用户具有法定年龄才能签订有约束力的合同。这意味着您的应用程序的13至17岁的用户必须让父母一方代表该用户接受该协议。
• Twitter的开发人员政策禁止批量注册应用程序和“域名抢注”，其定义为“以不同的名称提交具有相同功能的多个应用程序”。对于Twitter是否将不相关的用户（已将一个应用程序的单独副本注册为“域名抢注者”），我没有任何先例。

我要回答，但要警告我，我自己还没有解决，我不介绍最佳实践和现有的相关经验；

我不会太担心。如果您的客户端是开源的，那么他们无论如何都将有权访问源代码，并且试图控制自己对程序的操作始终会违背开源的本质（尽管重要的是，您尝试执行的操作并非如此）。

如果某人具有足够的知识来调试您的程序并提取您的密钥，那么他们可能会知道如何做以外的事情，您很可能会浪费时间尝试进一步锁定。

作为预防措施，我会每隔一段时间（如果可能）更改密钥，但是如果它们能做的只是装作您的程序，那对我来说听起来并不那么严重。

完全公开，我不熟悉Twitters API，twitterizer的API，oauth要求或我说过的其他有疑问的内容；）

使用者密钥和机密是应用程序绑定的，而不是用户绑定的。通过这种形式，OAuth提供程序知道它正在处理什么应用程序。其余步骤，访问令牌和机密将在第一步完成后获得。

请参阅此博客文章以获取更多信息，因为它显示了协议的工作原理。