I'm working on a personal project that is an app that deals with user mental health data. Because of the sensitivity of the data, and the fact that the app syncs with the cloud as apposed to loading data directly from the cloud, I decided to switch from JWT access token + opaque session token to an opaque access token. This is because it provides more token control (can revoke the session token instantly) and the increased request duration is not an issue (since it would just make the sync process slightly slower, which is not noticeable at all).

My understanding is the purpose of the refresh token in a JWT based configuration is that there's no way to revoke the JWT without storing revoked JWTs in a database and looking them up every time (which would defeat the point of a JWT). So you use a short-lived JWT and a long-lived refresh token.

This doesn't seem helpful when the actual access token is revokable though - couldn't I just make the access token long-lived?

1 Answer 1


You can increase the access token lifetime if you're using opaque tokens (which are indeed easy to revoke), and you may omit refresh tokens entirely in this scenario. This is effectively the classical server-side session approach which is used as an alternative to standards like OAuth.

However, the lifetime of the access token should still be limited. You can only stop an attack by revoking the token if you've already detected the attack. This usually takes some time -- or doesn't happen at all. So the lifetime should be as short as possible, especially when you're dealing with sensitive data. Depending on how long your users actually interact with the application, this could be anything from 15 minutes to maybe an hour. If your users want more, they should explicitly request that, e.g., by ticking a remember-me checkbox.

You must log in to answer this question.

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