2
votes

I'm beginning a Single Page Application, and I'm using Javascript Web Tokens to Authenticate client side (JS Client with Server API).

In my app, user provides credentials (app auth, facebook, google) and then server checks for user existence and returns a token.

Client JS adds token to each request in order to use the Server API.

When token gets issued, it has an expiry time and a max refresh time. If a set a short expiration time for the token and a "good" max refresh time I get into having to know when to refresh tokens. Best approach I've found so far, is to check on client when the token is being expired (5 minutes before) and then issue a refresh request. Then I'd get a new token. This could be done till max refresh time is reached. Then, user should have to reauthenticate.

Another approach I've seen, is that on server, if token is nearly or has just expired, it gets autorefreshed and returned to client (which has to detect token change and store it)

But... what is the difference between this and having single token to live the "good" sesion time?

Is having a short lived token which can be renewed without auth tons of times better than having a single long token?

1

1 Answers

0
votes

The primary reason to use a short-lived token is to defend against session hijacking, when an adversary, through one method or another, steals session credentials (in this case, the token) and acts maliciously in the victim's session. The shorter-lived the token, the less time the attacker has to carry out whatever malicious activity they have planned.