0

I'm currently developing a REST API which is supposed to be consumed by my App and desktop website. The user should not need to login every single time.

Currently I implemented the following:

  1. First call to auth with username&password -> master token is returned (valid for 1 month) and stored in the DB. On client side, it's stored in local storage.
  2. Call to access token endpoint with master token. Check if expired, if not check in DB if it's revoked by the user. Return 15 minute access token
  3. Every secure resource needs the access token. If it's expired, the client needs to provide the master token to the access token endpoint again.

If the master token expired, a new login is required. By the way, how would I do that without disrupting the user flow? Let's say he creates something and just at that moment the master token expired. Simple login popup?

Real question is: Let's say the user uses the incognito mode to Login. I create a master token in the DB. The user closes it. Since no logout happened, the refresh token stays in my database until it's really expired (1 month). if my users use a lot of these modes, the database may hold many master tokens which might never be used (since they aren't remembered by any application). Is there a flow to deal with that? Or just live with having them in the database?

Seems to be a bit confusing if you have tons of signed in devices in the "Signed In Devices" list.

0

It's not necessary to create a (random) token and store that up to a month. Instead, you can just digitally sign the login data (userid+login timestamp) and let the app use this signed chunk of data to prove that the user logged in less than a month ago. Or you might just use Keycloak or something similar, because rolling your own security-related code is often a bad idea.

You also might want to remove the "non-real" question about user re-login because that's mainly a UI issue....

| improve this answer | |
  • The token would be a jwt containing user id, expiration and unique identifier. If i just use a signed chunk a user could never sign out on all/this device as you can with WhatsApp, Facebook etc. or he would have to login every time he opens the app. I don’t want to sent the password with every request either. – petul Mar 2 at 17:54
0

There are several ways you could help yourself here.

You could issue a much shorter master/refresh token and issue a new one everytime you issue an access token (probably wise as that's a long time in the case of it falling into the wrong hands). This would mean that you're holding those tokens in your database for a much shorter period of time. Knock on effects are regular users never actually re-login and sporadic users have to login more often. There would also be a processing overhead, so you may want to consider upping the time an access token is valid for.

If your use case is actually handling revoked tokens (which hopefully would be an edge case), then you could just record instances of revocations. So check would be is user (held in JWT) on revoked list, if so, was token issued before rev date, if so, not authorised. This would mean all tokens for a user would be revoked on all clients, but it would also provide a way of easily killing all a users token off if you were actually revoking the user.

| improve this answer | |
  • Issuing a refresh token should require authentication. So it’s not really great if i send a new one every time an access token is requested. Revoking should only happen for the same reason you terminate e.g Facebook logins. Maybe lost your phone etc – petul Mar 2 at 17:50
  • If it requires authentication, it's not a refresh token, in the OIDC sense at least. But I get this isn't really an OIDC implementation. – K Mo Mar 2 at 18:17

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.