Child Item

Intermittent "code has expired", on authorization with .NET SDK

I have integrated Dropbox into a software running on a touch-screen kiosk type Win10 machine, using the provided .NET SDK.

Because a web browser is not available, the user has to generate a Dropbox authorization code in his Desktop computer, and then type the long received code into our software, so that the SDK can exchange the authorization code by a token.

To get the token I am using:

await DropboxOAuth2Helper.ProcessCodeFlowAsync(authorizationCode, appKey, appSecret);

With the received token, I am then building an instance of the client:

var client = new DropboxClient(token, new DropboxClientConfig() { HttpClient = client });

However, on average, 2 out of 3 attempts will thrown an OAuth2Exception with message: invalid_grant and error description: code has expired (within the last hour)

Sometimes, after successful authentication the token seems to get revoked by the server after a while.

These machines are running on older version of Win10 (from 2015/2016) and cannot be updated.
Recently I have updated them to use TLS 1.2.

This has been going on since I integrated, more than an year, and recently seems to happen more and more frequently.

Find more posts tagged with

Developers

Accepted answers

Scott-DB

Hi @giovaniluigi,

Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

It seems though more at issue is the exchange a code for a token. If I understand correctly, all codes must be transferred manually from the computer to your kiosk, and so it's possible your users are sometimes taking more than the five minutes these tokens are valid for. In addition, if they don't type it in exactly correctly then it won't work.

Your use case sounds like what the OAuth 2.0 Device Authorization Grant was designed for. However currently Dropbox does not offer this flow. I will however bring this up with our team to see if we can in the future.

All comments

Здравко

@giovaniluigi wrote:
...
Sometimes, after successful authentication the token seems to get revoked by the server after a while.
...

Hi @giovaniluigi,

You should take in mind that all new access tokens are short lived access tokens (you can distinguish them with starting "sl."). Despite an existing long lived access token can still be used (if you kept any), new cannot be issued anymore (they are deprecated some time ago and issuing dropped already). If you want processing within your application, without user disturb for re-authentication, refresh token should be used. The refresh token doesn't expire itself (till explicit revoke). You are constructing your Dropbox client object using access token alone (with the constructor here)! That's where your issue is coming from - access token can alive for 4 hours, at most. Use another constructor (suitable in your case) that relies on refresh token instead. 😉

Good luck.

giovaniluigi

Thanks @Здравко for your answer on that problem. I imagined the temporary revoke would be a problem related to the time limit mentioned in recent posts, but I thought the SDK would still work.

These are breaking changes... We don't see that often these days.

Now that still does not answer the issue while trying to exchange authorization code by token.
That one is currently my biggest issue.
I don't see how a server that issues an authorization code, would say that this same code has expired a few seconds after generating it.
To me that is non-sense. But that is what the SDK says on the exception.

Здравко

@giovaniluigi wrote:
... I imagined the temporary revoke would be a problem related to the time limit mentioned in recent posts, but I thought the SDK would still work.
These are breaking changes... We don't see that often these days.
...

😯 Wow... If you have seen that is less than 100% after 4 hours... 🙂 You have discovered something like perpetuum-mobile. 😁 But while working for you it's Ok.

About the rest. 🤔 Some piece of code reproducing the issue (piece that can be compiled and run) would be a good start point. Let's hope there is somebody here able to direct you through once there is a example to evaluate.

giovaniluigi

Hmm, I meant that its not often that a big company update their server and break all existing code running on their own SDK

About the code to reproduce the behavior is really 1 line:

await DropboxOAuth2Helper.ProcessCodeFlowAsync(authorizationCode, appKey, appSecret);

That call will throw, complaining about authorization code expired, for a code that is not supposed to be expired (i.e. generated a few seconds earlier)
Now of course that its not for all users. It works 100% of the time for some users on different machines, while for others will fail like 2 times out of 3.

That obviously is not the most used authorization flow (manually entering the authorization code) so there is much less data about issues.

It is also more vulnerable to validation issues for many reasons, especially given the fact that the code is generated in one machine, then entered in another one. I wonder if this is part of the problem. Usually an authorization code is valid by itself and should not require additional security checks, like client name, IP, location...

Здравко

@giovaniluigi wrote:
Hmm, I meant that its not often that a big company update their server and break all existing code running on their own SDK
...

Hi @giovaniluigi,

Might be said, but how would you improve something like long lived access token when it's considered insecure? 🧐 Actually all existing tokens work still, only new can't get issued. In such a way there is back compatibility.

You "code" is not something opaque that can securely reproduce the state. The statement is context sensitive! It depends on how you have launched your browser (your URL), for example. The set of required arguments can vary and their format too. Selected authentication flow is very important! That's why a single line of code (like your) isn't enough. Can you write a dummy program with this line and reproduce the issue? 🙂 That's what I'm asking for.

@giovaniluigi wrote:
...
It is also more vulnerable to validation issues for many reasons, especially given the fact that the code is generated in one machine, then entered in another one. I wonder if this is part of the problem. Usually an authorization code is valid by itself and should not require additional security checks, like client name, IP, location...

In general, there should not be a problem URL to be launched on different machine and then produced code returned back. This can't be a problem itself. The statement that "authorization code is valid by itself and should not require additional security checks" is definitely not true!!! That's exactly what your "code" is doing when launched - code verification together with all other passed arguments (let's imagine there is some required argument, but you don't pass it). 😉 And most probably this assumption is leading to such consequences. Be more careful... with the context.

giovaniluigi

If I create a console application and write that 1 line of code passing the provided argument that can be generated from the Dropbox console, it will generate the result I am saying. It will throw (sometimes... hence my problem).

Also, for the .NET SDK that one line call is for a static method in a Helper class, and should carry no context by convention. The context you are looking for is the SDK requests, the OS, the connection, network driver, IP, location... Exactly what I am looking for here, since I don't know what the server is looking during validation, and the Dropbox SDK provides a message that conveys doubtful information. Even if I trust the message and assume that the token is indeed expired after seconds of being generated, the question "why?" remains.

The idea to have the authorization code is to give trust to the owner of that authorization code. If you need to interrogate that owner, then you can't trust the owner to begin with. So that is my point. Possessing the code is enough for that purpose. And it is the only data that the Dropbox page provides you anyway. If different machines would not be a problem, as you said, that is basically saying: who presents me the code is trustworthy

Scott-DB

Hi @giovaniluigi,

giovaniluigi

Hi @Scott-DB, hmm you really provided one critical piece of information there.

So the auth code is only good for 5 minutes. Now it starts to make sense.

I believe that this time window has not always been respected. So that is very likely the cause.
As you know, the manual code is pretty long... so it makes sense that 5 min is probably right on the edge...

Yes, the Device Grant would be the best option for us.

To make easier for our end-user, I am implementing a similar idea where the kiosk device polls our own servers...

IOT devices and small touch panels would benefit a lot from it.