title: How do I get an OAuth request_token from live.com?
body: <p>It may be a duplicate question but there hasn't been an answer yet. The libraries oauth-dot-net and DotNetOpenAuth are both frighteningly convoluted, a theme that seems to run through OAuth, and while 
  <a href="https://stackoverflow.com/questions/4002847/oauth-with-verification-in-net">OAuth with Verification in .NET</a> is instructive and much easier to understand, it says</p>
  
  <blockquote>
    <p><em>Use a WebBrowser control</em>, and open the authorize web page within the
    desktop app. When the user clicks "Allow", grab the response text from
    that WebBrowser control, extract the PIN automatically, then get the
    access tokens. You send 5 or 6 HTTP requests but the user needs to see
    only a single Allow/Deny dialog. Simple.</p>
  </blockquote>
  
  <p>This is OAuth without a browser? No, it <em>isn't</em>. It works, provided you use a web browser to invoke the URL and run the response, which is an all-singing all-dancing miracle of browser based automation in HTML, meta refresh, noscript tags and javascript. But I do not wish to do this. </p>
  
  <blockquote>
    <p>Microsoft, this is aimed at you! I need to do pure REST, not <em>mostly
    REST except when it's javascript</em>.</p>
    
    <p>I wish to retrieve a request token, as described by the OAuth RFC. A
    request token, not a software authentication robot. <strong>A REQUEST
    TOKEN.</strong></p>
  </blockquote>
  
  <p>When I use WebClient to directly execute this GET</p>
  
  <pre><code>GET /oauth20_authorize.srf?client_id=00000000400A9B87&amp;scope=wl.signin%20wl.basic&amp;response_type=code&amp;redirect_uri=http%3a%2f%2fwhitehouse.podzone.net%2f HTTP/1.1
  </code></pre>
  
  <p>I get back an unspeakable mess of machine generated javascript. For the love of Pete, I want a goddamn request_token, not a javascript love-in. So, how the blazes do I get a request token from live.com? </p>
  
  <p>I'm currently wading throught the obfuscated and compressed libraries referenced by the sent HTML, but it's heavy going. If anyone has already done this I would be very grateful for assistance. Or even guidance on how to hijack and trace the script on this page, which would probably speed things up a fair bit.</p>
  
  <p>If you're examining the GET, the redirect URI <a href="http://whitehouse.podzone.net/" rel="nofollow noreferrer">http://whitehouse.podzone.net/</a> maps through to the webserver on my home desktop machine, which is usually an HttpListener in the application being debugged, or sometimes IIS. That's how  I process the redirect (usually just drop it, but it's nice to know things got that far).</p>
  
  <hr>
  
  <p>I have a short term hack lifted from some work I did based on someone else's work around Skydrive. It avoids the problem by exploiting the fact that the Skydrive application is pre-approved for every Live account. However, this is a hack. I'd like to use OAuth properly, it just doesn't seem like that's going to be practical.</p>
  
  <hr>
  
  <p>Despite a really gutsy attempt to help from Darin, which turned up some stuff I wish I'd seen on day one, I'm left with this quote from his link <a href="http://msdn.microsoft.com/en-us/library/live/hh826529.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/live/hh826529.aspx</a> (my emphasis)</p>
  
  <blockquote>
    <p><em>To implement the client-side authentication flow, desktop apps must
    use a web browser control.</em> Most development languages include such a
    control. In this example, our app uses the
    System.Windows.Forms.WebBrowser class. <em>After sign in is complete</em>, all
    subsequent Live Connect API calls can be accomplished by using the
    System.Net.WebRequest class. Use the web browser control to start the
    sign-in, passing a URL similar to this one.</p>
  </blockquote>
  
  <p>They only want me to use their robot for sign-in because relinquishing control of the exchange makes it harder to skip presenting a user intervention opportunity. There is no <em>inherent</em> reason I can't implement the sign-in procedure myself. Anything their javascript can post I can post with WebClient. I can do the same encryption. On an ethical level the user would hardly be presenting their username and password if they didn't want my software to do its thing.</p>
  
  <p>I've marked up Darin's answer because he's tried very hard to assist and presented some excellent stuff, but I guess I'll be sticking with my little hack which is disappointing.</p>