Decode token that has expired

[danny305]

It would be nice to be able to decode and grab the claims (and identity) from either an access token or refresh token that has expired so that information could be utilized. Something like jwt.decode(token, verify_exp=False) would be useful.

We discussed this: https://stackoverflow.com/questions/54106546/flask-jwt-extended-current-user-identity-none-when-creating-non-fresh-access-t

[vimalloc]

Thanks for opening this issue. I was thinking about it more the other day, and instead of providing a helper function for that, I think it be easier to pass the dictionary of the expired token to the @jwt.expired_token_loader callback function, so that people can modify how they want that to work in an intuitive way.

We could implement this with depreciation warning without making a breaking change the same way that we handled things in #212.

[danny305]

What do you mean by pass a dictionary of the expired token? I thought the token is just a base64 string? Could you provide an example on how to use this updated @jwt.expired_token_loader callback function?

[vimalloc]

Yep. It hasn’t been merged yet, but an example of what I’m planning can be seen here:
https://github.com/vimalloc/flask-jwt-extended/pull/221/files#diff-9570d0b23c3cb956412b9193933415b2

I’ll update this ticket when I have that merged and a new release cut.

[danny305]

Is there a reason that in the expired token loader callback you don't have a keyword argument to refresh the token automatically if the client has a valid refresh token? Also, what is the reason that these callback functions aren't written as 1 class so we could just create a subclass and be able to modify individual loader callbacks as need? I am interested in your reasoning.

[vimalloc]

For sure, these are some good questions 👍

For your first point, if we had an auto refresh setup it would lock people into a single way of doing things which goes against the building principles of this extension. For example, some people may want to return the JWT in a header, some in a cookie, some in JSON payload, etc. Additionally, people may want to store the newly created token in a database so it can be monitored and and blacklisted later, while other people might be using redis/memcache/mongo/etc to perform token blacklisting, and others don't blacklist tokens at all. Trying to have an automatic refresh schema that would satisfy all use cases would be nearly impossible and make this extension much harder to use. In fact, in the 2.x version of this extension I had a single way to do things in regards to token blacklisting and it caused a bunch of issues for users, which is what prompted me to rebuild that feature and release a breaking change in the 3.x release.

Per your second point, in the flask ecosystem it is much more common to see decorators instead of subclassing. This has been used for many flask extensions such as flask-login, flask-celery, and the original flask-jwt. I opted to use decorators for the callback functions to keep this extension in line with what people are already more used to seeing in the flask world.

[vimalloc]

This has been released in version 3.16.0.

Cheers.

[danny305]

Thank you.