We're making changes to the Community, so you may have received some notifications - thanks for your patience and welcome back. Learn more here.
Forum Discussion
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 scheme...
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.
Greg-DB
Dropbox Staff
Dropbox StaffDropbox 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.
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.
