Add support for jti claim

[avimeir]

Hi all,

I'd like to add the support for jti claim to the package. The idea basically would be to store a list of expired jti's somewhere on the server side, and allow to blacklist specific tokens.

The way I'm thinking about the implementation is:

• Use pymongo to store the blacklist (rather than a django specific mongo package, makes our solution portable to vanilla python or other frameworks)
• Generate a long enough jti claim that will have negligible probability of being produced twice before the first one expired (string of 20 random ascii_letters and digits maybe?)
• Store the jti and the entire payload in mongodb, this will help us clean up the collection when a JWT is past the expiry date (so we don't grow the collection ad infinitum)
• Add a flag in api_settings.JWT_ENABLE_BLACKLIST, if True we add the jti claim to the payload in jwt_payload_handler()
• Check against the mongodb collection everytime we decode a JWT (if JWT_ENABLE_BLACKLIST is True) and if the jti is blacklisted treat it as if the JWT is expired

I have made an initial commit to a fork of the package, with my suggestion on how to implement this, you can find it here: https://github.com/avimeir/django-rest-framework-jwt/commits/master

Happy to discuss this!

Cheers,
Avi

[jpadilla]

@erichonkanen maybe you'd like to check this out

[erichaus]

Interesting, I hadn't heard of JWT ID before... seems like this overlaps with my earlier search for a way to invalidate a token. What are your thoughts on adding mongo as a dependency to this package? The implementation looks good at first glance

[jpadilla]

MongoDB as a dependency is definitely a no. We should probably just include a default implementation that uses Django cache backend, like how throttling in DRF works.

[gcollazo]

I believe Django cache is not the right solution since cache contents can be evicted or lost at any time. If I understand correctly, when you blacklist a token that token should be blacklisted forever. In that case using the DB is right choice.

I suggest creating a model DRFJWTBlacklist and store blacklisted tokens there. With this solution enabling a token blacklist feature will require DB access on all protected HTTP request. This should be an option and not the default behavior.

[erichaus]

@gcollazo what are you suggesting for the default behavior?

[jpadilla]

Yeah that sounds about right. But having said that we should provide handlers like what @avimeir did. We shouldn't care where the user stores and checks for blacklisted tokens. Optional default implementation could definitely be provide a model, properly indexed, unique constraints, etc.

Also, I think UUID's might better for the actual jti.

[gcollazo]

👍 for what @jpadilla said. Consumers of this package should be able to store and check for backlisted token wherever they want.

Providing a basic implementation that used django models sounds like a good idea but should be disabled by default. Users must enable this feature (if they want it) and specify if they want to use the bundled model backed implementation of token blacklist or use a custom one they can implement themselves.

[jpadilla]

Good read about Blacklisting JSON Web Tokens.

[avimeir]

So to summarize the main changes you would make:

1. move from mongo to a model that uses the default django ORM settings
2. use UUID for the jti instead of the random string I've created

Am I missing something?

Happy to fix my code and issue a pull request, unless someone from the core contributors wants to take ownership. As long as it gets done and we can use it in our project - all solutions are fine with me

[jpadilla]

@avimeir yeah that sounds good. Feel free to submit a PR. No one else is working on this right now.

[erichaus]

I pulled down @avimeir code so far and tweaking it to use a model with UUIDField (either through django-uuidfield or native if > 1.8).. seeing if I can get it working etc.. if @avimeir has update before then i'll check it out

[erichaus]

@avimeir @jpadilla touched up the code to provide default get and set handlers for blacklisting and a default model implementation... let me know your thoughts

0c0f946

PS havent tested yet but will this weekend

[tachang]

Is JTI meant to be used as a session identifier?