CODEWITHSUNDEEP
c#oauth
Peter Wone
Peter Wone

Reputation: 18795

How do I get an OAuth request_token from live.com?

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 OAuth with Verification in .NET is instructive and much easier to understand, it says

Use a WebBrowser control, 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.

This is OAuth without a browser? No, it isn't. 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.

Microsoft, this is aimed at you! I need to do pure REST, not mostly REST except when it's javascript.

I wish to retrieve a request token, as described by the OAuth RFC. A request token, not a software authentication robot. A REQUEST TOKEN.

When I use WebClient to directly execute this 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

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?

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.

If you're examining the GET, the redirect URI http://whitehouse.podzone.net/ 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).

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.

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 http://msdn.microsoft.com/en-us/library/live/hh826529.aspx (my emphasis)

To implement the client-side authentication flow, desktop apps must use a web browser control. Most development languages include such a control. In this example, our app uses the System.Windows.Forms.WebBrowser class. After sign in is complete, 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.

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 inherent 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.

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.

Upvotes: 3

Views: 2944

Answers (1)

Darin Dimitrov
Darin Dimitrov

Reputation: 1039298

You could use the implicit grant flow with rich client applications (grant_type=token). The idea is to have a WebBrowser control which initiates the authentication flow by redirecting to the live.com authorization server and providing a callback url. If the user authorizes your application the live.com will redirect back to the callback url and pass the access token in the url:

http://contoso.com/Callback.htm#access_token=ACCESS_TOKEN

You could then retrieve the access_token fragment of the url from the WebBrowser and use it to perform authenticated requests. You do not need to parse the returned content inside your WebBrowser. What you need to do is to retrieve the access token from the url.

There's also the authorization grant code flow (grant_type=code) which is more suitable for web based applications.

You might take a look at the following article for a complete sample using a desktop application.

Upvotes: 4

Related Questions