Issue 757: Blacklist tokens

mslowiak commented 2 years ago

Summary of change

Blacklisting tokens based on:

existing account (if using token for not existing user - forbid)
time of email change (if using previous token after password change - forbid)

Related issue

Closes #757

Pull request checklist

Please keep this checklist in & ensure you have done the following:

[x] Read, understood and adhered to our contributing document.
- [x] Ensure that you were first assigned to a relevant issue before creating this pull request
- [x] Ensure code changes pass all tests
[x] Read, understood and adhered to our style guide. A lot of our code reviews are spent on ensuring compliance with our style guide, so it would save a lot of time if this was adhered to from the outset.
[x] Filled in the summary, context (if applicable) and related issue section. Replace the square brackets and its placeholder content with your contents. For an example, see any merged in pull request
[x] Set this pull request to 'draft' if you are still working on it
[x] Resolved any merge conflicts

For any of the optional checkboxes (e.g. the screenshots one), still check it if it does not apply.

knjk04 commented 2 years ago

@mslowiak Thanks for working on this! I'll review this at some point this week

knjk04 commented 2 years ago

@mslowiak I've taken a very look over this and noticed you're not creating a table to store blacklisted/already used tokens. Is there a particular reason for this?

mslowiak commented 2 years ago

@mslowiak I've taken a very look over this and noticed you're not creating a table to store blacklisted/already used tokens. Is there a particular reason for this?

@knjk04 Yes, the initial thought was to save every token in a separate table... However, this approach saves some time! If you think about tokens, there is a refresh token and an access token. To deactivate the token after logging out/ changing the password you would need to store the refresh token and access token. When refresh token is not a problem because it is usually long-lived, the access token is short lived, and saving it will hit db every time that refresh token is exchanged to the access token.

As a conclusion to that, I decided to keep the timestamp of the last password change date. At every authenticated request we just query this table - if there is no user it means that he was deleted and the token is no longer valid. When the user exists we just validate if the issue date is after the last password change date.