bcryptjs has the same limitations as the original bcrypt: it only takes the first 72 bytes of the string, and just discards the rest. For JWT, this means that the header and, with luck, half of the payload will be hashed, which can easily be repeated from token to token with a simple payload.
So, this leads to the fact that even after Refresh token is updated, the old token is still valid, because those 72 bytes used for the hash are exactly the same.
If for some reason you want to use bcrypt specifically, the token can be reversed before hashing so that the 72 bytes used for hashing include the signature of the token. It is guaranteed to be different.
But it is better to change the hashing tool to something like argon2.
https://github.com/mguay22/nestjs-social-auth-refresh/blob/3256c20e41bf713f208b79d8dc0e93ef58c57a4f/src/auth/auth.service.ts#L57
bcryptjshas the same limitations as the originalbcrypt: it only takes the first 72 bytes of the string, and just discards the rest. For JWT, this means that the header and, with luck, half of the payload will be hashed, which can easily be repeated from token to token with a simple payload.Proof for bcrypt Proof for bcryptjs
So, this leads to the fact that even after Refresh token is updated, the old token is still valid, because those 72 bytes used for the hash are exactly the same.
If for some reason you want to use
bcryptspecifically, the token can be reversed before hashing so that the 72 bytes used for hashing include the signature of the token. It is guaranteed to be different.But it is better to change the hashing tool to something like argon2.