Better documentation on revoking request tokens

Hey all,

I came across #53 which talks about how to revoke a refresh token. It is kind of unclear what exactly this comment references https://github.com/vimalloc/flask-jwt-extended/issues/53#issuecomment-309292786 and revoking refresh tokens isn’t mentioned anywhere else. The only place with some documentation is this random site: https://darksun-flask-jwt-extended.readthedocs.io/en/latest/blacklist_and_token_revoking/ which does not appear to be official, or even tell you what version it’s talking about, and it doesn’t work anyway.

Basically I’d just like a blurb to be added to the refresh token page saying that they can be revoked in the same way as auth tokens as long as verify_jwt_in_request(refresh=True) (or the equivalent decorator) is included. It’s just too easy to slip a developer’s mind that refresh tokens do indeed need to be revoked, to prevent generating a new access token after one was invalidated.

I think there’s also a possible implementation of allowing tokens to be tied a session cookie, then invalidating all refresh/access tokens for a specific session via a logout endpoint. But that’s complicated above my use case.

[tgross35]

@Jordon-Chen you’re lucky to have caught me in the midst of a long docker build 😃

My current method is like you said: I have /auth/access and /auth/refresh routes that accept POST to generate and DELETE to revoke access and refresh tokens, respectively.

You could theoretically have one endpoint that does it all using verify_jwt_in_request(optional=True) with and without refresh=True and seeing which one returns, but that seemed more effort than it’s worth.

[tgross35]

@vimalloc I just wrapped up changes for this in #460, take a look when you get a chance

I think this will play nicely with #441. The new argument I added verify_type currently accepts a bool - this could be expanded to accept a string or iterable of a custom type. If you OK #460, I’ll look at bringe #441 in.