19

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 up 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.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Daniel
  • 191
  • 1
  • 1
  • 3
  • 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. – Steve Sether Feb 10 '16 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. – Steve Sether Feb 10 '16 at 22:36

2 Answers2

10

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.

Chloe
  • 1,668
  • 3
  • 15
  • 30
2

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.

Community
  • 1
Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • 2
    The tokens are issued by the 3rd party. There is no control over how long they are valid. – Chloe Feb 13 '16 at 00:39
  • @steve-sether Even though short lived, would you still save them encrypted in the DB? – AlikElzin-kilaka Sep 11 '16 at 07: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. – Steve Sether Sep 11 '16 at 20:55
  • Interestingly enough, Bearer Tokens issued by PayPal last 8 hours... – Alexis Wilke Aug 25 '17 at 17:01
  • 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. – Rodrigo Murillo Apr 07 '18 at 05:10