Dropbox Sdk refresh access token encapsulated

[yurpub]

Hi guys,

your Sdk is great, however I don't understand something.

Inside I found a method CheckAndRefreshAccessToken(), that in turn calls RefreshAccessToken() that retrieves new access and refresh tokens which are then set in DropboxRequestHandlerOptions (see below). However, since this class is internal I can't access these two data pieces that I need to pass via constructor in the future calls.

JObject jobject = JObject.Parse(awaiter2.GetResult());
            string str = jobject["access_token"].ToString();
            DateTime dateTime = DateTime.Now.AddSeconds((double) jobject["expires_in"].ToObject<int>());
            this.options.OAuth2AccessToken = str;
            this.options.OAuth2AccessTokenExpiresAt = new DateTime?(dateTime);

Can someone shed some light on this please?

[Здравко]

Hi @yurpub,

You didn't clarify what SDK and what version you are referring to.

Generally talking when you have got refresh token you don't mandatory need anything else. Depending on which SDK you are using, there is some way to build  new client object with the owned refresh token and dummy other arguments (when they are needed). If new client object is going to be constructed relatively often, you can keep your old access token and expiration time and reuse them. This can be done without accessing any internal code/data. There is usually some authentication object you can serialize to and restore from data stream. 😉

Hope this helps.

[yurpub]

Dropbox.Api v. 6.29.

Constructor of DropboxClient accepts access and refresh tokens, expiration date.

When connecting a DB account, I'm able to store an access & refresh tokens + expiration from DropboxOAuth2Helper.ProcessCodeFlowAsync(). Great!

When an access token expires, the Sdk takes care of this by refreshing the token and setting it in DropboxRequestHandlerOptions instance. Great! But how do I access it? 🤔

I now need to create DropboxClient class again. Supplying the old access token+expiration doesn't make sense. Although it'll work because Sdk will make a call to refresh a token. Means, it's going to refresh token every time we want to access a client's account.

Would you please share an example of how to access new access token and expiration date?

[Greg-DB]

Thanks for following up. I see you're using the Dropbox .NET SDK.

As long as you supply the necessary credentials when creating the DropboxClient object, the SDK should handle the refresh process for you automatically, without you getting the expired access token error yourself or needing to call CheckAndRefreshAccessToken or RefreshAccessToken explicitly. You don't need to directly access each new short-lived access token that the SDK retrieves, since it will automatically use it itself. The refresh token itself doesn't expire and can be re-used repeatedly, so you would create the DropboxClient with the same refresh token whenever needed (whether or not the short-lived access token is expired).

Please refer to these examples for information on how to use the .NET SDK with refresh tokens. Specifically, look at these lines for samples of how to supply the necessary credentials:
 

• https://github.com/dropbox/dropbox-sdk-dotnet/blob/main/dropbox-sdk-dotnet/Examples/OauthBasic/Progr... 
• https://github.com/dropbox/dropbox-sdk-dotnet/blob/main/dropbox-sdk-dotnet/Examples/OAuthPKCE/Progra...

 
PKCE is meant for client-side apps. Note that the app secret is required when not using PKCE, and is not required when using PKCE.

[yurpub]

Thanks for your examples.

The problem is that there is no way to access a new access token in your SDK.

Why is this the problem? - because once an access token has expired (that was received only once), SDK is going to refresh an access token every time we want to access a client's account.

In other words, the access token received in the first place (after consent screen) can be used only once.

We implemented custom code to check the expiration of the token, refresh it with a separate HTTP call to POST: /token and store a new access token in the database to be able to reuse it while it's alive.

It should not be like this. Apologies for such feedback 😀

Thanks.

[Greg-DB]

Thanks for following up. I'm not sure I understand your use case though. Can you elaborate? Why do you need to be able to retrieve the current short-lived access token?

The recommendation is to just create the client with the credentials you have and let the client perform the refresh automatically, whenever needed (even if that includes doing so on every subsequent client creation). Performing the refresh is relatively light-weight.

And for reference, each short-lived access token can be used more than once, during its lifetime (several hours). Likewise, you don't need to create a new DropboxClient for each API call. You can keep any given DropboxClient in memory and use it as long as you need.

[yurpub]

each short-lived access token can be used more than once, during its lifetime (several hours)

---

That's correct. In most cases where the oAuth protocol is implemented, you intend to use the access token until it expires and refresh it when needed. That's a standard.

We may access the client's account within an hour multiple times.

If the DB SDK returns an access token to a developer following the authorization, I presume it's here to consume the API with a way to refresh it. But it's only available for 2 hours ever.

Anyway, our solution works.

Thanks for checking our my feedback.