2

This is my first time working with JWTs so I decided to ask here on Information Security as I'm very unsure about my approach towards JWT Authentication. I'm currently working on an API that will serve both mobile application and web page (React and React Native) and the authentication is currently being done with a JWT where both Access and Refresh tokens when the login is successful.

I currently have no mechanism to blacklist/revoke tokens but I'll work on it since the tokens carry roles on it's payload and tokens should be revoked when the user has it's roles changed.

The frontend developer said that he's going to store the tokens on cookies by using react-cookie to use on each request and refresh the token when it expires. Is that the correct approach and will the cookie be encrypted when stored? What security measures should I be concerned about with this approach? Thank you beforehand.

0

It's better to store refresh token in the database rather than a cookie. As anyone can view the token at front-end, decrypt it and might misuse it to attack your site.

  • Could you give an example of an attack this would allow? – IMSoP May 21 at 14:00
0

Ultimately, the user has the ability to trigger actions on your API, via some chain of authentication. The difference between storing the JWT in a cookie, and storing it on a separate server, is the number of steps in that chain: does the user's browser authenticate directly to your system, or does it authenticate to an intermediary, who then authenticates to you?

Encryption is largely irrelevant here: the user does not need to know what the token means, they only need to be able to send requests including it. If the browser can do so, anyone with access to that browser can also do so. If you want information in the JWT to be confidential, you can use an encrypted rather than signed JWT.

Moving the JWT from the user's browser does not automatically add any security, but it allows the intermediary to perform additional checks; for instance:

  • If the permissions granted to a particular JWT are quite broad, the intermediary can narrow those down by only passing on some requests.
  • An intermediary which is closely coupled to the UI can more easily implement defense against CSRF, ensuring that requests are only passed to your API if they originated from a valid application flow.
  • The intermediary can implement its own invalidation flow - if the user has a stateful session in some key-value store, that store can be cleared to log them out, and the user has no way of retrieving the JWT.

It is possible for all of these checks to be implemented in the primary API, so this partly comes down to "purity": you can make certain assumptions in your API design if it will always be accessed via a trusted server which you cannot make if it is accessed directly by untrusted clients.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.