Closed reft closed 7 years ago
@reft You're supposed to send the token along in the request, so you can still verify who they are. The old token has an id, which is part of the refresh token to indicate a pair. For that reason you should always send it along, and you should always know the identity of the client.
@RWOverdijk Right now I'm sending the current refresh token when I want to refresh the access_token, I don't use the expired access_token. Should I validate the expired access_token aswell? If I validate the expired access_token I get an "token has expired". What am I supposed to do with the old access_token? Should I compare the old access_token [JTI claim] with the current refresh token [JTI claim] or should I compare something else? Thanks :)
Aha.. So this token id is generated automatically, (i dont set any id when I create a new token), when i create a JWT token and both the access_token and refresh_token share the same id? Is that the only thing i should compare with the two?
Also, should this id be hashed or encrypted in both access and refresh?
It's the iat, you want to set the iat on the payload of the refresh token.
@RWOverdijk iat = issued at, (datetime). Are you sure you didn't mean jti, (unique identifier)? Should I be comparing the two dates instead? :S Im using the same guid for the jti on both tokens. Should I be hashing them? Thanks again.
@reft That's an option, too. In case you do't have that ID, you can use the iat. https://github.com/SpoonX/sails-hook-authorization/blob/master/api/services/AuthService.js#L218
That's fine, too. Whatever secret you wish to use so you can send them both in.
Ah perfect thanks
Can you use the auto refresh token feature to refresh before the access token is expired?
If the access token is still alive I know who that user is and I can restrict the WebAPI call to authorized users. At the moment I have to allow anonymous users to refresh token. I also have to decode the token before I know who that user is.