Architecture – Is caching Access Tokens on the back end of a Web Application a good idea? (access_token storage best practices)

Architecturecachingjwtoauth2openid

Let's suppose we have a Web Application that uses an Open Id Connect service provider, the Web Application uses the Authorization Code flow to get access to a different API, and therefore gets an access_token and an id_token at the end of the exchange.

So, now that we have an access_token to our API, we'll include it in every request we make to the API and therefore successfully authenticate to it and get back the resource we wanted.

However, and this what my question is about, of course we won't keep asking for the access_token every time we want to send a request to the API, so we'll have to store the access_token somehow so we can keep using it until it expires.

The question is: How do we store that access_token?

Do we store it in memory? Do we cache it? If we do cache it, is using a distributed cache a good idea? Is caching an access_token a good idea in the first place?
I mean, won't that defeat the purpose of having a stateless JWT in the first place if we're going to store information about the user anyway?

Best Answer

No, You should not cache access tokens on the backend of a web application.

You should store them client side and send them with each request.

Some applications will store the refresh token for a longer period of time, say months, in a cookie or local storage so that you don't have to login every time you launch the application.

Related Topic