0

I'm using JWTs for authenticating users for my mobile and web applications in the same API.Both access_token and refresh_token have same expiration

 Passport::tokensExpireIn(now()->addHours(1));
 Passport::refreshTokensExpireIn(now()->addHours(1));

When a user logs in

  1. authenticate (username and password) store access token (client-side) while for the refresh_token (I don’t use it at all)
  2. If the access_token is expired then it will go directly in signing in again (#1 repeat)

My Question: Since the expiration will last an hour and thinking the process is secured enough. Is there something I'm missing?

I do understand using the refresh_token.

  1. If the access_token is expired then it will use the refresh token to get a new access token + new refresh token. (requires the client id and secret)
  2. The presence of the refresh token means that the access token will expire and you’ll be able to get a new one even without the user’s interaction
  3. is intended to automatically detect and prevent attempts to use the the same refresh token in parallel from different apps/devices.
  4. mitigates the risk of a long-lived access_token leaking (which in my case not applied)
  5. Once the new access token + refresh token generate in using the refresh_token Those previous access_token and refresh_token will be useless or revoked

My Question: Should I use the refresh_token? I am thinking of saving it back-end or server. Setting the expiration lasts longer than the access_token, which is still 1 hour but for the refresh_token making it 1 year unless revoked. Once authenticated then it will generate using the refresh_token sending the new access_token in the client_side then saving the new refresh_token again in the server and so on. This will do everytime he/she logs in or register. Do you think it's okay to save the refresh_token in the back-end?

2 Answers 2

0

It sounds to me like you might be mixing up the use-case for access tokens. They are not designed to authenticate users for your application; they are meant to authorize a client application to work with a resource server API on behalf of the user.

If you are simply looking to authenticate a user for your apps, you should instead use the id_token provided by OpenID Connect. The id_token is designed to provide your applications with the details (in the form of JWT claims) that they need about the authenticated user; this is intended to allow each of your applications to initiate their own sessions, based on those claim details. As such, your session can be as long or as short as you need - it is independent of the session of the user in the AS (or OpenID Provider/"OP", as it is known in OIDC vernacular).

1
  • Isn't that distinction mostly only useful (to the degree it is at all; you say "not designed" and "should" but give no explanation or justification) in SSO? In an app where the auth is first-party, and the token is sent the client (browser or mobile app or whatever), what's wrong with using the access token as a stateless but opaque-to-the-client session token? The server can return everything that the client might want to know about the user directly - no need to stuff it into a JWT - but the lifetimes of the token(s) become very important indeed.
    – CBHacking
    Mar 27, 2022 at 13:44
0

It is extremely awkward to revoke a JWT, without violating the statelessness that is their main advantage in non-SSO contexts. As such, the standard practice is that the JWT is very short-lived - usually a few minutes - and the refresh token is stored in the DB (hashed) and used to re-issue the access token when it would expire. Essentially this is a hybrid system: on most requests you get the statelessness of the JWT, but the refresh token (which can be invalidated/revoked) allows the JWT to expire quickly when the user logs out or their session otherwise ends, at a cost of one DB call.

The lifetime on the refresh token can be whatever you want. An hour, a year, a century - depending on whether you want to force people to log in again or not. You can also make it rolling (as long as it's getting used, its expiration is pushed back) if you want. As for when to refresh the JWT, you can do that automatically from the server when it expires (if JWT is expired, check for a valid session token to get new JWT), automatically from the client when the JWT expires (if the server returns an access error, call the refresh endpoint to get a new JWT), or automatically from the client before the JWT expires (using script to periodically refresh the JWT a few seconds before expiration, so long as the page is open).

You must log in to answer this question.

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