When you log in, you store the Access Token in the client header and the Refresh Token in Redis. And when the validity period of the AccessToken expires, the logic is used to check the expiration period of the RefreshToken by using the AccessToken as a KeyValue and reissue the AccessToken if it is valid. At this time, if the attacker steals the AccessToken, the attacker will also be able to obtain a new AccessToken even if the AccessToken expires, and it is expected that the attack will continue until the RefreshToken expires. When renewing AccessToken, I wonder if other conditions should be added instead of just checking the key value or if it is okay as it is. Also I wonder why this is ok
2
Answers
The idea is that you will make the lifetime of an access token very short and share it across different APIs without worrying. However, for refresh tokens you would be more careful and don’t use it any where except the authorization server. (Do not store in the browser nor in other APIs).
This will ensure the safety of the refresh token and the short lifespan of the access token will ensure its safety.
I had the same concern before and I got clear explanations that you can check here
how is using JWT refresh token secure?
This part is wrong. The client needs to send the refresh token to the Authorization Server in order to get a new access token. Ideally, the refresh token endpoint should require client authentication, e.g. the client has to send a secret or present a concrete certificate in a TLS connection. Unfortunately, this can’t be achieved when you have public clients, like SPAs (unless you use some kind of middleware, like the Token Handler.
Anyway, in order to get new access tokens, the attacker would have to get hold of the refresh token, not just the access token. If the client is confidential, then the attacker would also have to steal the client’s credentials (like a secret or a certificate’s private key)