I'm using .NET 6 with HttpOnly cookie-based JWT authentication in my WebAPI, and I'm now implementing token refresh.

I store the JWT and a Refresh Token in cookies, e.g.:

X-Access-Token: eyJhbGciO...
X-Refresh-Token: d8085ec8-d0bc-4e5c-b6b6-cd76146c419f

Most flows I've found for token refresh look like this, with the client calling the /refresh endpoint to get a new JWT:

1. client sends request to server
2. server rejects request with a 401 Unauthorized
3. client requests new JWT (expired JWT and Refresh Token automatically sent to server in cookie)
4. server validates cookie Refresh Token, generates new JWT and Refresh Token, assigns to cookies
5. client sends original request to server, with the new JWT and Refresh Token in the cookie

My question is:

When the initial request with the expired JWT is received by the server, since the server already has the refresh token (sent in the X-Refresh-Token cookie), can't the server issue a new JWT and Refresh Token at that time and successfully complete the request? This completely eliminates the need for a separate request and response to refresh the tokens. This is the flow:

1. client sends request to server
2. JWT is expired, but Refresh Token is valid
3. server creates new JWT and Refresh Token, assigns to cookies
4. server successfully completes the request

Is there a vulnerability or security risk implementing the refresh this way? I cannot think of one, but I could not find any examples with this flow.

Thanks!

CodePudding user response：

Why are you using JWT access tokens? If the server could respond with an updated access token by looking at the refresh token, then why wouldn't the server just look at refresh tokens every time, and then the JWT access tokens aren't needed?

The point of using JWTs, and access tokens in general, is that it allows stateless authentication with services that have no access to the refresh token store. Usually, you will have an authentication service, it stores the refresh tokens, and calls to /refresh get routed to it, and it will validate the refresh token, and issue the access token. Then, calls to other services are able to validate the access token, without needing to make any calls on the authentication service. So, the reason why they don't just reply with a new access token when authentication fails is because those services are incapable of checking the refresh token, they don't have access to the refresh token store, only the authentication service does.

If however your application is one big monolith, where every endpoint is hosted by the same server and therefore is capable of checking refresh tokens and issuing access tokens, then there is absolutely no reason for you to be using access tokens or JWTs in general. You should just use refresh tokens, which, in this case, would be better called a session token.