4

I have a solution for an authentication system without using refresh token. Please tell me where are the vulnerabilities of this method.

I assume the following:

  • Client and Server are on the same domain.
  • Client is a browser that support HttpOnly cookie.
  • Client is using a Single Page Application.

The steps are:

  1. User login by making a request to /api/auth with the credentials.
  2. Server authenticate the user and send back a Set-Cookie Header with an HttpOnly cookie containing a JWT.
  3. Client receive and set the HttpOnly cookie. Client also set in Local Storage a variable logged: true.
  4. After sometime User reopen the browser. The Single Page Application check if the variable logged in Local Storage is == true. If so check if it still has the HttpOnly cookie by making a request to /api/check-cookie.
  5. Server respond with true if it find the HttpOnly cookie and it is valid. Otherwise false.
  6. Client, if receive false from /api/check-cookie, will prompt the user with the login.

With this approach the JWT can have a long expiration date and there is no need to keep track of refresh tokens.

Am I missing something?

47ndr
  • 583
  • 5
  • 23

1 Answers1

0

I like your thinking and had similar ideas, particularly with setting a local storage variable to reflect the state as logged in so I could check that before making a pointless server call to refresh a token that potentially doesn't exist, however, I'm still using the refresh token.

I believe the crux of your issues will be when the user updates on the server side, it won't be reflected on the client side until the user re-authenticates with a new long-lasting, singular token as opposed to when the short-lived access token refreshes, setting the user again with the updated data.

Klh
  • 134
  • 14