OAuth 2.0 where to securely store access token for long term use

Question

I am working with API that uses OAuth 2.0. Its' flow is like this:

1. In your application, you have a button which redirects you to the authorization server (APIs' in my case).
2. You either have to log in to APIs' website and give access to your application (press "allow" or "deny" button) or if you are already logged in, just give access to your application (press "allow" or "deny").
3. You get redirected back to your application with your new access token for making API calls.

Everything works for me, all is good but what I do not understand is how to deal with given access token so that the user, which has already authorized access to your application, would not have to give access again. Etc when he comes back to the application after a few days. It gives bad user experience (no one wants to grant access again and again).

Note: I am working with Quizlet API

Answer 1

First of all, Access tokens should be short lived. Consider it equal to short lived one time credential. If you are not convinced, check Azure AD token life time definitions linked here "Configurable token lifetime properties".

Its recommended to use define short lived access tokens, for example which expires after 1 hour. That way you avoid the complexity of storing them. You simply keep them in memory and use them to access protected resources.

what I do not understand is how to deal with given access token so that the user, which has already authorized access to your application, would not have to give access again. Etc when he comes back to the application after a few days.

Well, here you should be talking about Refresh tokens. According to OAuth 2.0 specification, its refresh tokens which have longer life time. If you check with my earlier reference to Azure, you see that they can live up to 90 days. For Google, refresh tokens expire after 6 months (if they are not used). One can still revoke them.

Now when you are using refresh tokens, you are not using them to access protected resources. Refresh token should be exchanged to get access tokens. So if someone steal them, they still need client authentication (ex:- client id, redirect uri & client secret) to obtain access tokens. Still, protecting them is a must.

Regardless, RFC6819 define some possibilities you can take on in section 5.3.3 to store secrets (tokens are secrets). You may use a client storage mechanism or utilise server backed to store tokens.

If your application has an back-end, one possibility is to correlate cookies to tokens. Cookie value could be a hash of the token which you have stored in back-end(probably in a database). When the back-end receive a request with a valid cookie value, it can retrieve the token stored against it. This is quite similar to "remember me" functionality.

What if you can't control token life time (They are by default long lived) ?

If you can obtain tokens hassle free, and if you can compromise end user experience, go for in memory storage where you will always retrieve new tokens for fresh access.

If you have a back-end for you application which can maintain the state between clients, push and store tokens at the back-end. Correlate client session with tokens, probably through cookies/sessions. Call secure APIs through back-end, without exposing stored tokens to client application.