I am creating a web server for a site with authentication using JWTs. Since this is going to be a publicly available system once ready, I would like to know if the following authentication flow using JWT access and refresh tokens could be considered secure. In this case it is assumed that one server serves both the auth API and resources

When the server starts, it will generate a "run ID" which is the current UNIX timestamp and random characters/UUID. This is stored in memory and any restart will generate a new one.

The user obtains an initial HttpOnly access and refresh tokens when logging in or registering. Access token has a short lifespan (~5 mins.) and refresh token has a longer lifespan (~2 hours).

The access token functions like normal and contains the userID. The refresh token has the userID, the server's run ID and its own unique "token ID" (similar to run ID, unique for each refresh token)

Instead of the user calling a token refresh endpoint, new access and refresh tokens are made when calling an endpoint that requires authorisation if the following criteria are met:

1. The access token has expired
2. The refresh token has not expired
3. The run ID in the refresh token matches up with the current run ID
4. The refresh token's token ID isn't blacklisted

In the event that there is a run ID mismatch or the token ID has been put on a blackist, the refresh token is instantly considered invalid. The token ID blacklist is stored in memory (like the run ID) as an array with the ID and expiration time. This allows a user to logout and blacklist that specific refresh token from being used. This also allows any system administrators to emergency invalidate all refresh tokens by restarting the server since the runID will change.

I would like to know if this can be considered a secure authentication flow