Authorization via copy/paste of OAuth2 access token?

[palant]

PfP: Pain-free Passwords is normally used as a browser extension, but I also provide a web client. That web client is supposed to be downloaded and run from local file system, so there is no real redirect URI to receive the authorization token. With Google Drive, a special urn:ietf:wg:oauth:2.0:oob URI can be specified as redirect URI. This will produce a page with the authorization code that the user can copy manually and paste into the application - that's the only way authorization can work in my case. Does Dropbox provide functionality like that? If not, could it be added maybe?

Of course, I could put up a page on my website that will display the authorization token to the user. However, this means that users have to trust my website. The very point of downloading the web client is that they don't need to trust the server.

[Greg-DB]

Yes, if you use response_type=code and omit the redirect_uri parameter entirely, Dropbox will display the authorization code to the user on the Dropbox web site so they can copy/paste it.

[palant]

I'll try that. So far I didn't test the code flow because my understanding is that using client secret isn't optional then. This is suboptimal in my case given that the web client cannot keep secrets. Google Drive allows omitting the client secret for client-only applications.

[Greg-DB · Accepted solution]

That's correct, the client secret is required for the code flow.

If you want to use the token flow, you can use response_type=token and redirect_uri=https://www.dropbox.com/1/oauth2/display_token (as long as you register "https://www.dropbox.com/1/oauth2/display_token" for your app). The token flow doesn't require the client secret, and the display_token page will just show the access token itself to the user for copy/pasting it.

[palant]

Great, this is exactly what I needed. Thank you!

[Sam S.6]

The website "https://www.dropbox.com/1/oauth2/display_token" mostly works, but does seem to inlcude a number of scripts which fail in many browsers. For instance, in Safari 12.1, the generic app icon does not get replaced with the client's app icon and the account-header render's without a profile picture. In Firefox 68, the situation is much better. 

I don't know enough about java script to debug this, but it seems to me that the code comes from API v1 times and might no longer be compatible with some browsers.

Edit: I was accidentally using "https://www.dropbox.com/1/oauth2/authorize_submit" with the code-flow in Firefox. This makes more sense now. Still, the "display_token" website could be a bit nicer. For instance, the HTML code references a "Copy token" button which does not appear.

Here is a side-by-side comparison:

[Greg-DB]

@Sam S.6 Thanks for the note! The icon on the display_token page actually doesn't use the app's own icon in any browser (unlike the authorize_submit page), but I'll pass this along as a feature request. I can't promise if or when that might be implemented though. 

Also, the profile picture for the account is rendering for me in the header on the display_token page for me in Safari 12.1.2. Are you sure you're signed in to an account with a profile picture set in that browser?

The "Copy token" button is only shown if the browser supports the mechanism used to copy it to the clipboard. I'll also pass this along as a feature request to see if we can update that to be more universally supported.

[Sam S.6]

@Greg-DB, thanks for the quick reply!

Ok, I so this is all expected behaviour. I am not sure if the display_token page can actually identify the client, since no client_id is passed in the fragment. I guess  the proper way would be to create my own redirect page...

As for the profile picture, I am definately logged in and can see my profile picture in a different browser tab.