The "jti" claim should be optional?

[JThinkable]

Thanks for all the work on this!

The jti claim seems to be required when it should be optional. This makes it tough to use with a provider that thinks it's optional. Is there a way to disable this check?

# Make sure that any custom claims we expect in the token are present
if 'jti' not in data:
    raise JWTDecodeError("Missing claim: jti")

4.1.7. "jti" (JWT ID) Claim

The "jti" (JWT ID) claim provides a unique identifier for the JWT.
The identifier value MUST be assigned in a manner that ensures that
there is a negligible probability that the same value will be
accidentally assigned to a different data object; if the application
uses multiple issuers, collisions MUST be prevented among values
produced by different issuers as well. The "jti" claim can be used
to prevent the JWT from being replayed. The "jti" value is a case-
sensitive string. Use of this claim is OPTIONAL.

[vimalloc]

Making the jti optional wouldn't be too hard to do with this extension. Before the 3.0.0 it would have been, but with the changes to how blacklisting tokens are handled, it is no longer required by various functions in the extension. However, this will inevitably lead to the next question, can we make the other values optional as well, namely type and fresh, and that gets trickier. Making these optional is certainly a possibility, but it would complicate the code with various edge cases and functions that don't work if the type isn't there (ex @refresh_jwt_required or @fresh_jwt_required would fall on their face if type and fresh wasn't in the token).

In the past I have been against the ability to optionally remove these, as it would complicate the code and possibly add a bunch of extra edge cases when working with this extension. And having a bunch of edge cases in an extension like this which specifically handles security seems like a not great thing. My recommendation at the time was always just to use PyJWT directly and make your own @jwt_required decorator if your application was just going to be consuming JWTs make by a different source.

However, I have seen a lot of similar questions raised recently (ex: #1 #72 pallets-eco/flask-jwt#122). Perhaps I should look into this more and see if I could provide this functionality with flask-jwt-extended. Alternatively, maybe I can think about forking this extension and strip out all the special helper stuff (blacklists, refresh tokens, csrf, etc). so it is just built for creating simple tokens or consuming tokens from other sources. Call it flask-jwt-simple or something.

I'll need to think on this some more before going forward. I would love to hear any feedback you or anyone else might have.

Cheers.

[vimalloc]

One other possibility that may actually be simple enough is to do the same type of thing that was done in #69. Instead of failing if an item isn't there, have it default to a specific value (something like if type isn't there, assume it is an access token and save it as such in the resulting python dictionary, and same thing fresh). That would keep the edge cases out of the application as the data in the python dict we are working on in the extension would match what we expect. On the flip side, it might be confusing as get_raw_jwt() would now be returning data that is in fact not in the jwt.

[JThinkable]

I was thinking something like @jwt_required(ignore='jti') but I don't know the testing impact. Clearly decorating with something like @fresh_jwt_required(ignore='fresh') would be an untenable scenario, but it also seems like it would easily testable.

I agree with not adding values that weren't really in the jwt in the first place.

[vimalloc]

(mostly notes for myself incoming, so I don't forget anything).

If we go this route, we would need to allow ignore to be a single element or a list of elements, which cause them not to be verified here: https://github.com/vimalloc/flask-jwt-extended/blob/master/flask_jwt_extended/tokens.py#L101-L114. We need to be sure this wouldn't cause breaking changes for existing use cases either.

The new code paths we would need to be aware of (at a glance) would be:

• fresh_token_required raises a new exception (not KeyError) if it is called and the there is not fresh value in the token
• refresh_token_required raises a new exception if type is not in the token.
• If type is not in the token, assume that it is an access token and treat it as such here: https://github.com/vimalloc/flask-jwt-extended/blob/master/flask_jwt_extended/view_decorators.py#L208-L209
• what to do with get_jwt_identity if the identity claim is not present in the token? Probably just raise another new exception?

If we do this, it would make sense to allow these values to be absent when we are generating tokens as well, so we should add options to account for that too.

I'm not 100% convinced this would be a good idea to add to this extension yet, but it seems like it would be a good feature to have. I'll start playing with these changes when I have some free time, and go from there. It will probably take a bit to get these going, tested, etc.

[vimalloc]

After thinking about this more, and coming up with more and more edge cases that would have to be gracefully dealt with, I am going to stand by my original decision to not make these claims optional in this extension. It would complicate the code too much for my liking, and make it harder to do additional changes to this codebase in the future.

Instead, let me introduce Flask-JWT-Simple (https://github.com/vimalloc/flask-jwt-simple). It is a toned down version of this extension with all the opinionated stuff needed for the extra features ripped out. This new extension allow you full control over claims when creating JWTs, and places no restrictions on what claims need to be in consumed JWTs.

If there are features missing from the simple variant of this extension that you would like to see, I would be more then happy to port them over. The two that I could see being helpful right off hand is JWT blacklisting and JWT claim verification. Both of those should work fine in this non-opinionated extension.

Hopefully this will be sufficient for your use case. If you have any problems or concerns, don't hesitate to let me know.

Cheers.