Using an embedded C# WebBrowser, we developed a Linkedin Oauth login library which would allow a user to receive an oauth access token.  We set the callback uri to something specific to our app – “myapp://success”  Within the WebBrowser_Navigating event, we’d look at the uri.  If it included “myapp://success” we were able to extract the access token from the query params.  However, this technique breaks down in a few scenarios:

1.  Using a Winform browser, the redirected uri was never sent as event arguments if the URI wasn’t http://, or mailto or other special cases.  This meant that we had to use a WPF browser which requires a bunch of overhead libraries to be loaded when all we really need is a winform.

2.  Previous versions of Internet explorer do not honor  passing the redirected uri to the WebBrowser control if the uri doesn’t actually exist.  So in other words, because the system didn’t know how to handle linkedin:// uri’s the browser would never redirect to that uri.

To solve the problem I tried to register a NOP callback in the registry to handle this URI scheme:

Register a NOP command line for the liconnect scheme in the registry as a URL scheme (i.e. a command line program that does nothing).

http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.createsink.aspx

The webbrowser still didn’t honor passing the URI scheme to the navigating or even the navigated event.  The URI being navigated to must actually exist for the Webbrowser to actually pass it to the event.

So, to solve it:

We set the callback URI to a URI that we own.  ie.  “http://mydomain.com”

This way, we’re able to intercept the callback when we see this uri in the navigated event.  I’m not thrilled with this solution since it relies on a server.  You could just as easily redirect to http://linkedin.com or some other known domain, but it still leaves your client code dependent on a server.

I’ve uploaded the most recent code to the original linkedin thread.