Provide AccessToken object to storeToken and removeToken methods

[longwa]

The storeToken and removeToken methods are not useful in many cases because you need access to the refreshToken (in both cases) and the principal (in the removeToken case).

The most common use case for these methods would be to implement some kind of stateful handling of the token (either a whitelist for active tokens or a blacklist of blocked tokens).

In both cases, you need to be able to handle both the accessToken and the refreshToken including access to other JWT attribute such as expiration, subject, etc. For instance, if you are trying to blacklist a token when the user explicitly logs out, you need to also blacklist the refreshToken since someone with access to the token could just use it to create a new accessToken.

My suggestion is to add additional method signatures:

void storeToken(AccessToken accessToken)

void removeToken(AccessToken accessToken) throws TokenNotFoundException

To keep backwards compatibility, we can just have these call the other methods by default in the JwtTokenStorageService.

The places that call store and remove will be changed to pass the AccessToken, allowing for more flexibility.

[longwa]

This is related to #298 as it would provide a better mechanism to implement it.

[alvarosanchez]

Seems legit to me. I was going to suggest that you propose a PR, but I see you're already in progress with that. Submit it when done and I'll review it.

[longwa]

One issue is that for removeToken it isn't really useful to have the full token as only the accessToken field is populated.

It's only when the AccessToken is initially created is all of the data populated (refresh token, principal, etc.). I still think it's useful to have the entire object on the call to storeToken so that it has feature parity with the event listener (which already gets the entire object).

I'll submit a PR once I have it all working in my real application to make sure there aren't any other surprises.

[jdaugherty]

https://github.com/grails/grails-spring-security-rest/pull/521 will resolve this.

[jdaugherty]

This is complete in the 5.0.x branch.