7

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?

Hamza
  • 89
  • 2
  • 6
  • If access_tokens are never stored, how do you think your mobile apps works? How do you think your main API providers invalidate access to the accounts? EVERYTHING is stored somewhere in the SE. The key is for how long and where. On the other hand, JWT is not meant to bear users information, they bear issues to prove its authenticity whether these are related to a given user or not is up to you to dice. Adding user's info to save some calls to the DB is implementation details too and irrelevant for the matter because the token is an id itself that points to a user or account. – Laiv Jun 05 '19 at 09:18

3 Answers3

1

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.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • Isn't that less secure then storing them in the back-end? What's the point of using the Authorization Code flow in the first place if you're going to expose the token on the front end ? – Hamza Jun 05 '19 at 10:58
  • It's not a great idea to make access tokens permanent, but temporary tokens are certainly feasible. Presumably you're operating in HTTPS secure mode anyway. An attacker would have to mount a MITM attack to take advantage of a persisted token; preventing that is the job of HTTPS. – Robert Harvey Jul 05 '19 at 18:25
  • @hamza sorry rereading your question I had got the wrong flow. Yes with the authorization flow the server can keep the keys. The idea is that the user has given the application permission to access the resource 'offline' ie not requiring the user to initiate each request – Ewan Jul 05 '19 at 22:56
0

Using a JWT (please don't say JWT token since this means "Json Web Token token") mainly has the purpose of not having server side state in the interaction between your client and your server. The second you have any persistence (like a database) this whole statelessness is only relevant on the session scope.

When you request access to a third party resource using OIDC you usually get two tokens (access and refresh) and you would expect your server to handle all the details about refreshing the token etc.; especially if the server is making requests on your behalf e.g. to sync a calendar or some other data. In that case it will need the tokens even when your browser is closed and thus, yes, it is a good idea to store them there.

Whether you use a cache or your db to store the tokens is only a minute detail. Just make sure they are stored safe and secure :-)

Christoph Grimmer
  • 159
  • 4
  • Thanks for the answer.I see you have experience in C#, so I have an other question, the Web Application is basically a dotnet core MVC application that uses Cookies to manage the user session in addition to the Open Id Connect authentication handler. What about the Cookies ? Do I store them somewhere? – Hamza Jun 05 '19 at 08:50
  • Please put this in a new question – Christoph Grimmer Jun 05 '19 at 14:03
0

If you use the authorization code flow, you should save the access token and the refresh token. The access token can expire after a period of time, therefore you need the refresh token to get a new valid access token. About the ID token. Its purpose is not to be used when calling protected resources via API. The ID token is used for authentication, not for authorization. I will ignore the ID token in your use case.

To me, there is no problem to save the access token and the refresh token in the server even in the long term period. That is the purpose of the refresh token to allow the client to generate new access token without prompting the user with a consense dialogue when the old access token expires.

Hieu Le
  • 663
  • 4
  • 10