Child Item

Using IdentityModel.OidcClient with Dropbox

Hey

I'm using the IdentityModel.OidcClient to authenticate the dropbox account of a user within my application.

The authentication works as expected with one exception: The redirect_uri. I'm using random ports within the redirect_uri to avoid connection problems e.g. https://127.0.0.1:{randomPort}. If I do so, I receive the following exception:

"Invalid redirect_uri: "https://127.0.0.1:51931": It must exactly match one of the redirect URIs you've pre-configured for your app (including the path)."

Is there a way to use random ports with the redirect_uri or do I have to use static ports? Is there a limitation to the amount of redirect URIs?

Thanks for help.

BTW: Google, Microsoft and Box.com support random ports for 127.0.0.1 as redirect_uri.

Find more posts tagged with

API

Abuse

Comments

Здравко

@CloudServices wrote:
...
"Invalid redirect_uri: "https://127.0.0.1:51931": It must exactly match one of the redirect URIs you've pre-configured for your app (including the path)."
... Is there a limitation to the amount of redirect URIs?
...

Hi @CloudServices,

If you take a look on the parts of your post, that I enlightened above, you will find out the response, I believe.

For Dropbox, URI can vary (arbitrary or not) within border of set of pre-configured redirect URIs, associated to your application. If particular URI (including loopback variation) is not there, error comes up. That's it. Take a look on your application settings.

To be honest, I don't understand what kind of connection problems you are trying to avoid and how port randomization would help you!? 🤔

Hope this clarifies matter.

CloudServices

Hi,

I don't know why, but my reply hasn't been accepted by the system. I'm trying to post now in smaller chunks.

I think I have setup the redirect URI the right way (to https://127.0.0.1), as I do for google & co. What I'm trying to find out is: Why Dropbox doesn't accept redirect URIs with random ports.

CloudServices

Example:

My registered redirect URI at google is https://127.0.0.1. If I now send an authentication request with the redirect URI set to https://127.0.0.1:51931. Google accepts this redirect URI, because the port doesn't change the destination.

Dropbox on the other hand seems to be very strict when it comes to the redirect URIs. The redirect URI from the authentication request has to match exactly the registered redirect URI (port included).

I would prefer to use random ports to avoid problems on machines where ports might be not available do to e.g. firewall settings. This way it's possible to switch from a blocked port to a free port without having to register another redirect URI.

Greg-DB

Thanks for writing this up! I'm sending this along to the team to see if we can get this supported. I can't promise if or when that might be done though.

Здравко

@CloudServices wrote:
...
I would prefer to use random ports to avoid problems on machines where ports might be not available do to e.g. firewall settings. This way it's possible to switch from a blocked port to a free port without having to register another redirect URI.

Aha... About the firewall: If your access is forbidden such a move is not gonna fix it. It's unlikely loopback port becomes issue, but if happens to be you should fix your firewall settings, instead.

Yes, it's likely some other service to engage some particular port and so block your application. More stable workaround is registration of few ports and try them sequentially. Very, very unlikely to be needed more than 3 tries. Even if your application falls in such a situation, it's most likely system issue, rather than your application issue. Restarting the system usually fixes the issue. Dropbox site uses the same approach. Linking the site to installed local application happens through port 17600. If it's engaged already, the following (17601) is on go to be tried. If needed, 17602 is going to try. If no one of all 3 ports provides proper response, the site assumes no working local application available. 😉 Just for example. Your situation is different but the same way may be used.

Hope this helps.

dgeiss

@Greg-DB
Thank you.
Other account, same author. 🙂

dgeiss

This is a solution, but not the desired one.
Let's say the application, that wants to make the authentication, runs on a device, that I can't administrate, because the device belongs to a customer. In this case it would be great to have the opportunity to switch to any port without having the need to register all possible redirect uri, port combinations.

Здравко

@dgeiss wrote:
...
Let's say the application, that wants to make the authentication, runs on a device, that I can't administrate, because the device belongs to a customer. ...

Hm... 🤔 Do you assume that Dropbox application can be installed only on devices Dropbox is able to administrate? 🧐🙂 I don't think so... 🤷 Dropbox is not an administrator on my laptop, where I'm writing now for example, but the application still work (including mentioned loopback port). 😉 You definitely don't need to be administrator on device where your application works on.

dgeiss

That's not what I mean. The application I am talking about, is the application that I am writing. This application will be installed on the customers device. The device of the customer can't and shouldn't be administered by me or by Dropbox.

Without having the ability to change the settings of a customers device, I have to add some flexibility to my application. In this case the flexibility is needed for the port, that is used in the redirect uri.

Option 1: Dynamic redirect uri - The redirect uri supports random ports OR

Option 2: Static redirect uri - Register many redirect uris (same destination but with different port number).

I prefer option 1.