Thanks for sharing, I think this is a great series, a lot of cool stuff to learn from it.
I have one question, is there a particular reason as to why HMAC has been used to generate the refresh token? Couldn't it be a randomly generated string?
I'm thinking that the server is the only source of truth, as far as the refresh token's correctness is concerned. If we keep track of refresh token by storing them in a { userId: refreshToken } manner, then if the client sends a different refresh token than what's currently stored, then we know that something is wrong, so maybe we could instruct the client to log out or something like that.
I did a bit of research on HMAC and a few takeaways are that it ensures these 2 things:
authentication - it ensures the sender is who we'd expect. in this case, the sender(i.e. the client) would send us(the server) something that we previously sent to them - the refresh token. So if the client sends something else than what we initially sent, then something is suspicious and no further actions should be taken. Thus, I see no need for HMAC here, a random string could be generated and then stored such as it can be verified against what the client sends. If there's any difference, then don't let the client do anything.
message integrity - ensures that the message has not been modified along the way. This looks like something that should be done for the access token, I don't see why the contents of a refresh token would matter at all. It boils down to the solution from the above point - if the server's generated string is different than what the client sent, then the client did something wrong. The way I see it is that the server is always right, because it is the one which generated the token and stored it.
What do you think?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for sharing, I think this is a great series, a lot of cool stuff to learn from it.
I have one question, is there a particular reason as to why HMAC has been used to generate the refresh token? Couldn't it be a randomly generated string?
I'm thinking that the server is the only source of truth, as far as the refresh token's correctness is concerned. If we keep track of refresh token by storing them in a
{ userId: refreshToken }manner, then if the client sends a different refresh token than what's currently stored, then we know that something is wrong, so maybe we could instruct the client to log out or something like that.I did a bit of research on HMAC and a few takeaways are that it ensures these 2 things:
authentication - it ensures the sender is who we'd expect. in this case, the sender(i.e. the client) would send us(the server) something that we previously sent to them - the refresh token. So if the client sends something else than what we initially sent, then something is suspicious and no further actions should be taken. Thus, I see no need for HMAC here, a random string could be generated and then stored such as it can be verified against what the client sends. If there's any difference, then don't let the client do anything.
message integrity - ensures that the message has not been modified along the way. This looks like something that should be done for the access token, I don't see why the contents of a refresh token would matter at all. It boils down to the solution from the above point - if the server's generated string is different than what the client sent, then the client did something wrong. The way I see it is that the server is always right, because it is the one which generated the token and stored it.
What do you think?