I am building a REST API back-end for a mobile application. In our design choice we decided to let OAuth2 providers handle the login security; however, I am not sure what the best practice is for the access token, which I acquire from the OAuth2 providers.

The situation is I get an access token from the OAuth2 provider when the user makes a login. I will need to use this token every time the mobile application makes a request to my back-end so I can validate against the OAuth2 provider to see if the token is still valid.

I know that I am going to create a JWT and hand it to the mobile application, which it will use every time it makes a request. Now my question is should I store the access token, which I got from the OAuth2 provider, inside the JWT as claims or should I store it in a database and connect it with the users' ID, which I will store in the JWT claims?

Perhaps it is recommended that I encrypt the JWT with JWE? If that is the case, will it decrease performance more if I decrypt for each request, rather than doing a database lookup (I will be using either MongoDB or Redis) or will performance impact be the same?

The connection to my REST API will be through HTTPS.

  • 3
    I think you need to decrypt this into something more understandable. We aren't all web developers up on the latest and greatest technologies. What are you REALLY asking here? Forget about all the gobbledygook about JWT, JWE, etc. What's the real question, and who are you trying to protect against? Security is often about thinking at a higher level than all the alphabet soup. Think about data at rest, and data in transit, plaintext vs cryptotext, and secret keeping, not specific technologies. Commented Feb 10, 2016 at 22:27
  • Also, think about how long you need your access token to be valid for. That limits how destructive the tokens leaking out would be. Commented Feb 10, 2016 at 22:36

2 Answers 2


If the request to the 3rd party API is through your server, then store the access token in the database tied to the user, encrypted with a key that is stored as an environment variable. If the database is compromised, the tokens are safe. (Bonus, encrypt the tokens with a key that is generated and stored on the mobile app.)

If the request to the 3rd party API is directly from the mobile app, store the access token on the phone, encrypted with a unique key for each user stored in your server's database. Decentralized storage of sensitive information is more secure than centralized storage (compartmentalization). If the phone is stolen, it requires authentication to your server before the decryption key can be obtained. If your server is compromised, the tokens are not there.

I've not used JWT.


Access Tokens are according to the RFC supposed to be limited access. Rather than worrying about where to store something of high value where the server might be compromised, it's better to simply limit the duration of access to the token.

This is spelled out specifically in the RFC for bearer tokens:

Issue short-lived bearer tokens: Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked.

  • 2
    The tokens are issued by the 3rd party. There is no control over how long they are valid.
    – Chloe
    Commented Feb 13, 2016 at 0:39
  • @steve-sether Even though short lived, would you still save them encrypted in the DB? Commented Sep 11, 2016 at 7:07
  • @AlikElzin-kilaka That's a bit of a judgement call. Adding an encryption layer has an added cost associated with it in terms of development time, and maintenance. It'd likely only really protect against a compromise of the database. If you think the database is at higher risk for a compromise than other parts of the system, then it might be worth the added cost. YMMV. Commented Sep 11, 2016 at 20:55
  • Interestingly enough, Bearer Tokens issued by PayPal last 8 hours... Commented Aug 25, 2017 at 17:01
  • 1
    Long lived, automated or scheduled access to an API provider would need a way to store and retrieve tokens for programatic access to the API. Using reasonable and prudent security practices, this is a secure and valid setup for this type of use case. Commented Apr 7, 2018 at 5:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .