Avoid refresh token for authentication when using HttpOnly cookie

Question

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?

Answer 1

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.