OAuth2 refresh token only valid for 14 days

Question

I have just upgraded our Box code to OAuth2.

We have implemented code that allow users to transfer files between our web server and their Box (as well as SkyDrive, Dropbox, Google Drive) accounts. The users's access and refresh tokens are stored in our database server.

As per http://developers.box.com/oauth/, it says Each refresh token is valid for 60 days

Both SkyDrive and Drive use OAuth2, and do not have refresh token expiry. Is it possible to have non-expiring refresh tokens?

Some applications may not need the refresh tokens, so would you consider introducing new OAuth2 scopes, e.g.

1. box.read
2. box.read_write
3. box.offline_access

Answer 1

As I understand it, the Box OAuth2 implementation uses the optional refresh token rotation scheme, where each time an access token is issued, a new refresh token is also issued. See section 10.4 of the oauth spec document. It is an optional feature, and one that Google and Microsoft does not employ, as they issue permanent refresh tokens for the OAuth2 implementations (or at least refresh tokens with a long enough lifetime, so its not really an issue).

This is, in my humble opinion, a very unfortunate choice on part of Box.

What you have to do in your applications is, each time you request a new access token, you also have to save the new refresh token you get back, so you use the new refresh token the next time you ask for an access token. That way, the only scenario where you will end up with an expired refresh token, is if the user doesn't uses their Box login for 60 days. As long as they actively use the app, you will get new refresh tokens and the 60 day life cycle is not an issue. So far so good, but that is not always how it works, now is it?

My problem with it is, that you have to save the refresh token on each request, but what if that fails for some reason: The is a network outage, the battery flatlines, there is a disk write exception, your app gets shut down by the OS.... then you will have to request that the user log in again, and the user is gonna blame the app developer.

And this is going to happen, if you have enough users using your app. Maybe only for 2-5% over time, but that is still huge problem in my opinion.

At least if the refresh token was (semi)-permanent, you could retry the auth process until it was completed. Then you knew you had the token saved, and you could continue using it, also for retries, when above scenarios happen, but not so with the rotation scheme.

I am already thinking of making a standard support email for my users who experience this issue, linking to this question.