OAuth2 implicit grant (token flow) does not work in IE/.Net Winform WebBrowser

Hi Steve,

I want to report I'm seeing similar issue when running the WebBrowser control under Windows Vista. It is most probably a bug/incompatibility in the WebBrowser. My current suspicion is that the WebBrowser control have an issue handling a redirect url which includes fragment (#) in certain situations. My question to you is why Dropbox does the redirect with fragment and not the regular query (?) tag when doing the token flow? 

Here are the steps to reproduce the issue in my environment.

1. Using token flow authorization.

2. The application has already been authorized.

3. The WebBrowser control opens a page asking to enter credentials. Enter credentials and press 'Sign in'.

4. The WebBrowser Navigated event is called. However everything after the fragment (#) is removed.

Handling the DocumentCompleted or Navigating events is not working either.

-------------------------

One more interesting observation. If I don't close the Desktop application and re-open the dialog containing the WebBrowser control, the Dropbox doesn't ask me for credentials and the token flow is called properly with the access_token fragment included.

"why Dropbox does the redirect with fragment and not the regular query (?) tag when doing the token flow?"

That's how OAuth 2 works. As to why OAuth 2 works that way, it's to prevent the token from being sent to the server. The query string is part of the URL that's sent to the server, while the fragment is not. The token flow is for client-side apps, so the fragment is a way to communicate the token to the app without having it leak elsewhere.

Nekobul, the behavior you describe sounds different from either of the issues already raised in this thread. It sounds like the Navigated event is called but the URL you see is lacking the URL fragment. Is that right?

One guess: if you're using https://www.dropbox.com/1/oauth2/redirect_receiver as your redirect URI, that page removes the fragment of the URL after a short period (e.g. to keep someone from copy/pasting the URL and leaking their token somewhere). Is it possible that Navigated is firing multiple times: once for the initial load of /redirect_receiver (with the URL fragment) and then once after the fragment is removed? Try logging/alerting in Navigated to see if it's being called more than once. The first call is the only one that will have the fragment.

Steve,

Thank you for the quick reply! When tracing using the Fiddler app, I see the following:

1. GET https://www.dropbox.com/oauth2/authorize request and Dropbox responds with 302 redirect with  https://www.dropbox.com/1/oauth2/redirect_receiver#access_token ...

2. GET https://www.dropbox.com/1/oauth2/redirect_receiver request and then response from dropbox.

I get only one call in the Navigated event handler and it contains only : https://www.dropbox.com/1/oauth2/redirect_receiver#

Nekobul, can you share your code for how you're getting the URI in your Navigated event handler?

The issue I'm seeing is very similar to the issue described here. However I'm not using WPF. The WebBrowser is the standard Windows Forms.

Steve,

The code works fine if I reload an other already authorized page. When running under the debugger, the supplied Url from WebBrowserNavigatedEventArgs is clearly maimed when authorizing initially.

Have you tried DocumentCompleted or maybe Navigating?

Also, have you tried using a different redirect URI, like https://www.example.org? I'm just curious if this relates to the JS on the page removing the fragment or if it's somehow an inherent issue with the event you're listening for.

Steve,

Yes, I have tried DocumentCompleted and Navigating. The fragment is not removed by Dropbox. As I've said I can see in Fiddler the correct redirect url with the fragment is provided. My suspicion is that the WebBrowser control has an issue handling the fragment element in certain situations. So the sequence which fails is:

1. The Dropbox page for authorization is opened.

2. The page expects entry of credentials and then pressing Sign-in.

If there is no user interaction involved, the fragment is properly provided in the Navigated event. If there is a WebBrowser user interaction involved, the fragment is maimed in the Navigated event handler.

"The fragment is not removed by Dropbox."

/redirect_receiver has JavaScript on it that removes the fragment after the page is loaded. The reason I'm asking about other redirect URIs is because they won't have that behavior.

Steve,

Guess what? You were right. The /redirect_receiver is indeed doing something. I have just tried different redirect_uri and it worked fine.