I’m currently attempting to use the OAuth 2.0 User-Agent Flow with a clientside C# application, and I’m running into some confusion relating to the redirect URI.
Because I’m working with a clientside application, I cannot supply a standard redirect URL to a web server. However, according to the people I’m trying to authenticate with (Salesforce, in this instance), the User-Agent Flow is the correct one to use for a clientside application.
My question is, what can I do to catch the access token in this situation? Apparently I can create a “local resource accessible to the client,” but I’m unfamiliar with the mechanics behind this, and I can’t find any resources on the topic (partly because I don’t know what to look for).
Any pointers as to where I should start looking would be greatly appreciated.
Edit: Some more digging has revealed the following stackoverflow question:
How do I develop against OAuth locally?
I’m doing some more investigating with what they suggested, but any other suggestions would be great as well.
Edit: Some more searching revealed this article:
http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html
Still feels like I’m poking around in the dark without an understanding of the larger picture, but I believe I need to set up a local web service using localhost and point my redirect URI there. I’ll then use my web service to unwrap the response from the OAuth server and have my application respond appropriately. More updates to come.
Ooookay. So from what I’ve been able to gather, I need to set up a local web service to supply as the callback for OAuth. I need to listen on said web service myself and catch the callback to pass it to my app. However, the default ASP.NET web service provided by VS2010 does not support URL parameters, just API calls, so I apparently need to use the WCF Rest starter kit instead.
I am completely foreign to all of this, so any tips would be a godsend at this point. In general, I’m thinking I set up a local WCF Rest service, supply that local URI to OAuth as the callback, and then catch the callback URL using the Rest service. Then I parse the URL and extract the access token. At this point, does my app request the access token, or can my web service “give” the token to my app? I.e., where should the locus of control be?
Figured out a clever way to work around this. Instead of setting up a service to listen for OAuth’s redirect URL, I embedded a WebBrowser control inside my Windows form.
I pointed this embedded WebBrowser to the authentication URL and let the user log in and authenticate with Salesforce and grant permissions to my app. Then, I let Salesforce redirect my embedded browser to a dummy redirect URL that I supply. This redirect never actually goes anywhere, it just shows up as a 404.
However, by monitoring WebBrowser.Url, I can pick up the entire URL that my embedded WebBrowser control is directed to, including the access token that is appended by Salesforce. Basically, after the user authenticates and grants permissions, the embedded browser is redirected to “http://www.dummyurl.com.” Salesforce appends the access token, so WebBrowser.Url ends up looking something like this:
http://www.dummyurl.com#access_token=ABCDEF&instance_url=ABCDEF
From here, I can just parse the URL and go on my way. No third-party web server or local web service required. 🙂