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

Could you share your code?

Also, have you seen https://blogs.dropbox.com/developers/2014/04/dropbox-authorization-in-a-windows-forms-app/. The code there, at least at the time I wrote it, worked. (But note that there I never tried a localhost URL.)

https://github.com/Kyrodan/KeeAnywhere/blob/develop/KeeAnywhere/OAuth2/OAuth2Form.cs

Hi Steve,

yes I know this Blog post and I found several such solutions. But I can't get it to work.

You can find my code here:

https://github.com/Kyrodan/KeeAnywhere/blob/develop/KeeAnywhere/StorageProviders/Dropbox/DropboxStorageConfigurator.cs

The problem is, that DocumentCompleted is not fired for the redirected URL.

Regards,

Daniel

We'll try to reproduce this. Could you tell us what version of Windows you're running on? (I assume Windows 10?)

I'm unable to reproduce this on Windows 10. I created a new Windows Forms app, added a web browser control to it, and wrote the following code. I saw a message for loading (among others), the redirect_receiver page, complete with an access token. Perhaps you can try this stripped-down version of the code and see if it works for you?

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        this.webBrowser1.DocumentCompleted += WebBrowser1_DocumentCompleted;
        this.webBrowser1.Navigate("https://www.dropbox.com/1/oauth2/authorize?response_type=token&client_id=0pr10otpma2qtln&redirect_uri=https://www.dropbox.com/1/oauth2/redirect_receiver");
    }

    private void WebBrowser1_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e) {
        MessageBox.Show("document completed: " + e.Url.AbsoluteUri);
    }
}

Hi Steve,

I tested it on 2 different Windows 7 machines and your reduced code does not work. What is different to your code: I changed app-id to my id because your app-id reached user limit.

Regards,

Daniel

Ah! I can reproduce this too, but only when the user is authorizing an app they've already authorized (so they skip the screen asking them to "allow" access). I don't understand why this makes a difference as to whether the DocumentCompleted event is fired, but it seems to. (You can try this yourself by revoking your app's access via https://www.dropbox.com/account/security and then trying again. You should see the DocumentCompleted event fire as expected.)

To fix this, I'd recommend using the Navigated event instead. This seems to reliably fire in both cases. I'm going to update the blog post to suggest that. Please let me know if it works for you.

Hi Steve,

I fixed it your way and it basically works.

But I encountered some weird behavior:

If authorization is done and redirected to https://www.dropbox.com/1/oauth2/redirect_receiver is performed I can grab the token from the URL. But additionally to that my standard browser (in my case Firefox) opens up with this page. That's not expected
If I'm not authorized in any browser the authorization flow askes to login. That's fine. But if I'm already logged in prior authorization the behavior differs whether I've already authorized the app (login page is displayed, after lgging in, not further step is required by user) or not (no login page is displayed; user has to authorize access).

Especially the first bullet point is not acceptable for me. Maybe the second could be solved by navigating first to logout page and after that to the authorization URL (that's the same behavior to other OAuth services).

Regrads,
Daniel

For #1, I have no idea what's happening, but I can't see how it would be a Dropbox issue. It certainly doesn't happen in the code I shared earlier, so it also doesn't seem to be an issue with the WebBrowser control under its default settings.

For #2, I had a little trouble following what happens under what circumstances, but it doesn't sound like the expected behavior to me. What I would expect:

If already logged in, no login page is displayed (i.e. no email/password fields present).
Otherwise, the login page is displayed.

Regardless of which of those happened:

If the user has an existing active access token for the app, they're not asked to authorize the app again (no screen with "allow" button). Instead, they're automatically redirected to the redirect URI.
Otherwise, the user is asked to authorize the app (click the "allow" button). Only after doing that are they redirected to the redirect URI.

Does that match what you're seeing or not?

Hi Steve,

I fixed my #2 by myself.

#1 is still open: On Windows 7 using your solution a web browser window is opened in the last authoriziation step (if the app was not authorized before). Your solution works on Windows 10 without glitches, can't try it on Win8/8.1.

Maybe the root cause is the different behavior of the WebBrowser control on Win7 and Win10 (seems to use different IE "compatibility"). I didn't got it fixed by myself without exchanging the WebBrowser control with another browser control (which I don't want).

Regards,

Daniel

Please let us know what you learn about the Windows 7 issue. Again, it can't really be the fault of Dropbox itself, but maybe there's a bug in the WebBrowser control? (Or maybe there's some *expected* reason why the WebBrowser control is supposed to launch an external browser, but that would be surprising.)

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.

Interesting. So I guess Navigated fires too late? But you tried Navigating as well, right? It seems like that should certainly fire before JavaScript on the page is executed.

Steve,

Yes, I have tried Navigating. It didn't work.

https://github.com/Kyrodan/KeeAnywhere/blob/master/KeeAnywhere/OAuth2/OAuth2Form.cs

Hi Ivan,

here you can find my working solution. Maybe it helps you:

I use the Navigated-Event.

The only drawback is, that due to the "JavaScript-Magic" the Default WebBrowser is opened on Windows 7 - no problems on Windows 10 (didn't ried on Vista,8, 8.1). In my opinion the JavaScript-stuff is crappy and not very stable. But I must say, that dropbox is one of the providers that implement OAuth2-Token-Flow "usable". For many others I need to use the Non-Fragment-URL-Way to a real existing Web-Server with a possible security problem - a no-go for a Desktop App.

Regards,
Daniel