Invalidate existing access tokens when scopes are updated

[myssto]

The one inherent problem with encoding user permissions into JSON Web Tokens as we do is the idea of stale permissions. Currently any issued access token will always be valid until it's expiry. The permissions we encode can become "stale" if we were to edit the scopes of the issuer (User or Client entity) before the expiry period is up. This could cause significant problems in the future when we implement the ability to restrict a user from submitting tournaments / matches.

For example, if a current User was issued an access token with the claim submit, and within that token's expiry we decide to ban this user from submission. That user still has a valid JWT with a submit claim until a new one has been re-issued.

Tasks:

• [ ] Identify and implement a strategy to invalidate a JWT that has already been issued and is not passed it's expiry
• [ ] Ensure that any implementation such as #191 can reliably take advantage of said strategy when scopes are updated

[myssto]

It is worth noting that a valid band-aid to this problem is to significantly lower the expiry period on access tokens. Currently the API issues tokens with a 1 hour expiry. If this were to be lowered, tokens would have to be generated more often, thus tightening the constraint on potential abuse.

From my perspective though, this is still just a band-aid and does not attack the root of the problem. JWTs with stale permissions will still exist, albeit for a shorter duration.

[hburn7]

JWTs are designed to not be invalidated. That is why the access tokens have such a short lifetime, and the refresh tokens (which do not have roles encoded) do not. When someone submits a tournament, we would probably run a db check anyway for that permission, and would not encode that restriction into the JWT. But I see where you're coming from, the services do need to make these checks when we implement #130

[myssto]

Ok after having talked this one through a bit, I realize that it is a valid point, but most likely a non-issue in our use case. o!TR Team is and always will be incredibly selective with granting elevated permissions and we have the response time to be able to intervene. I'll be closing this, but the main take away would be that is worth making sure to validate user and client permissions on a DB level for critical endpoints.