这可能是一个重复的问题，但还没有答案。它说，oauth-dot-net 和 DotNetOpenAuth 库都非常复杂，这似乎是贯穿 OAuth 的主题，而 .NET 中带有验证的 OAuth 具有指导意义且更容易理解
使用 WebBrowser 控件，并在桌面应用程序中打开授权网页。当用户单击“允许”时，从该 WebBrowser 控件中获取响应文本，自动提取 PIN，然后获取访问令牌。您发送 5 或 6 个 HTTP 请求，但用户只需要看到一个允许/拒绝对话框。简单的。
这是没有浏览器的 OAuth？不，不是。只要您使用 Web 浏览器调用 URL 并运行响应，它就可以工作，这是基于浏览器的 HTML、元刷新、noscript 标签和 javascript 自动化的全能奇迹。但我不希望这样做。
微软，这是针对你的！我需要做纯 REST，而不是主要是 REST，除非它是 javascript。
如 OAuth RFC 所述，我希望检索请求令牌。请求令牌，而不是软件身份验证机器人。请求令牌。
当我使用 WebClient 直接执行这个 GET
GET /oauth20_authorize.srf?client_id=00000000400A9B87&scope=wl.signin%20wl.basic&response_type=code&redirect_uri=http%3a%2f%2fwhitehouse.podzone.net%2f HTTP/1.1
我得到了机器生成的 javascript 无法形容的混乱。看在 Pete 的份上，我想要一个该死的 request_token，而不是 JavaScript 的爱。那么，我如何从 live.com 获得请求令牌？
我目前正在处理发送的 HTML 引用的混淆和压缩库，但这很繁重。如果有人已经这样做了，我将非常感谢您的帮助。甚至是有关如何劫持和跟踪此页面上的脚本的指导，这可能会加快速度。
如果您正在检查 GET，重定向 URI http://whitehouse.podzone.net/会映射到我家用台式机上的网络服务器，这通常是正在调试的应用程序中的 HttpListener，有时是 IIS。这就是我处理重定向的方式（通常只是放弃它，但很高兴知道事情已经走到了这一步）。
我根据别人在 Skydrive 上的工作，从我所做的一些工作中提取了一个短期的 hack。它通过利用 Skydrive 应用程序已为每个真实帐户预先批准这一事实来避免该问题。然而，这是一个黑客。我想正确使用 OAuth，但这似乎并不实用。
尽管 Darin 非常勇敢地尝试提供帮助，这发现了一些我希望在第一天看到的东西，但我留下了他的链接http://msdn.microsoft.com/en-us/library中的这句话/live/hh826529.aspx（我的重点）
要实现客户端身份验证流程，桌面应用程序必须使用 Web 浏览器控件。大多数开发语言都包含这样的控件。在此示例中，我们的应用程序使用 System.Windows.Forms.WebBrowser 类。登录完成后，所有后续的 Live Connect API 调用都可以通过使用 System.Net.WebRequest 类来完成。使用 Web 浏览器控件开始登录，传递与此类似的 URL。
他们只希望我使用他们的机器人进行登录，因为放弃对交易所的控制使得跳过提供用户干预机会变得更加困难。没有任何内在原因我不能自己实施登录程序。他们的 javascript 可以发布的任何内容我都可以使用 WebClient 发布。我可以做同样的加密。在道德层面上，如果用户不希望我的软件做它的事情，他们几乎不会提供他们的用户名和密码。
我已经标记了达林的答案，因为他非常努力地提供帮助并提供了一些优秀的东西，但我想我会坚持我的小技巧，这令人失望。