Child Item

Deep linking using custom url scheme

Currently I'm working on migrating my app from the OAuth2 token-flow to the code-flow with refresh tokens (as will be required in future by Dropbox). Now I'm facing the problem that custom url schemes like "com.example.appname" are not accepted as redirect urls of the code flow, and therefore opening the authorization page shows the 400 error message:

Invalid redirect_uri. When response_type=code, redirect_uri must start with "https://", unless it's a localhost URI.

The problem is, that Windows apps are not allowed to listen for https/localhost redirects, unless they where started with elevated admin privileges (which I want to avoid of course). UWP apps can register custom url schemes though, as is also common on other platforms like Android.

So my question, will Dropbox allow custom url schemes before the short lived tokens become mandatory, or how should we solve this dilemma?

P.S. My code-flow already works for other services like GoogleDrive or OneDrive and I'm aware of the solution with localhost plus port number, but free ports must be determined dynamically, they cannot be choosen fix, so we cannot register them in the developer console.

Find more posts tagged with

Developers

Accepted answers

Greg-DB

Dropbox does not currently have plans to change the redirect URI requirements when using the standard 'response_type=code'. You should be able to use a custom URL scheme like this when using the PKCE flow in particular though. You can find more information on using that in the authorization documentation and OAuth Guide. Please give that a try and let me know if that doesn't work for you.

Also, just for clarity (for you or anyone else reading this), note that 'response_type=token' itself is not being retired, so you can continue using that if you wish, even after September 30th, 2021. Dropbox will just no longer return new long-lived access tokens at that point, only short-lived access tokens. (Though, this flow doesn't support retrieving refresh tokens.) We do recommend the PKCE flow over the token flow though. (And the PKCE flow does support retrieving refresh tokens.)

Alternatively, if there isn't a suitable redirect URI that you can use in your environment, you can forgo use of the 'redirect_uri' parameter entirely, in which case the user will be just presented with the authorization code to copy/paste into your app manually.

All comments

Greg-DB

martinstoeckli

Hello Greg-DB

That's great, this is the missing piece I needed, thanks a lot!

There is simply no reason not to use the PKCE, I just didn't expect it to behave differently and used a test environment to create the URL. As soon as the "code_challenge" is included, the autorization page is shown correctly. The other alternatives wouldn't have been a solution, with synchronisation transparently in the background, copy pasting a code or login for each sync is way too cumbersome for users. But fortunately this is not necessary at all...

BTW your API documentation is really helpful, one of the best I had to implement so far.

Thanks again and best regards:

Martin

Greg-DB

Thanks! I'll also ask the team to clarify that error message to distinguish between PKCE and non-PKCE.