3.19.0

• Adds support for using multiple algorithms for decoding JWTs. Thanks @Darkheir! (#254)

3.18.2

• Fix JWT_SESSION_COOKIE = False creating a cookie that was too long in the future for some browsers (#243). Thanks @allen-cook!

3.18.1

• Fixes an issue when using decode_token on an expired token. This issue was introduced in 3.16.0. (#234)
• Require PyJWT 1.6.4 or newer (#238)

3.18.0

• Add the ability to dynamically set user claims via the new user_claims argument to create_access_token and create_refresh_token functions (#229). Thanks @jeanphix
• Add ability to use other datetime libraries for the token expiration configuration options. Anything that works with datetime.datetime (such as dateutil) will now work with extension (#233). Thanks @abathur

3.17.0

• Add the ability to use an integer (seconds) for the JWT_ACCESS_TOKEN_EXPIRES and JWT_REFRESH_TOKEN_EXPIRES settings. (#226) Thanks @evangilo!

3.16.0

This release changes how the @jwt.expired_token_loader callback function works. Before this release the callback function took no arguments. Now it will take one argument which is the decoded contents of the expired token. This lets you customize the expired token callback based on the token that was received. For example:

# Old way
@jwt.expired_token_loader
def old_expired_callback():
    return jsonify(foo='bar'), 401

# New way
@jwt.expired_token_loader
def new_expired_callback(expired_token):
    if expired_token['type'] == 'access':
        return jsonify(foo='bar'), 401
    else:
        return jsonify(foo='baz'), 401

The old way will still work, updating to this version will not break your software out from under you. You will however receive a deprecation warning when using that way. To fix this, simply add an addition argument to your callback function for the expired token.

3.15.0

• Adds the JWT_DECODE_LEEWAY option (#218). Thanks @otetard!
• Adds the ability to use other data structures besides lists (such as sets, tuples, etc) as config values (#215) Thanks @illia-v!

3.14.0

In this release we are modifying how decoded tokens work, so that this extension can be more easily used by other JWT providers (#212). The important changes in this release are:

• added the JWT_DECODE_AUDIENCE configuration option, for using the aud claim in JWTs
• Change the decode_key_callback() function to now take the unverified headers as well as the unverified claims as arguments. If you have existing code that only takes one argument, it will still work, but you will see a depreciation warning when it is called. You should update your callback to take a second parameter to fix that. As an example decode_key(claims) would become decode_key(claims, headers).
• If the jti claim doesn't exist in a token, it will now be set to None in the decoded dictionary instead of raising an error
• If the type claim doesn't exist in a token, it will be marked as an access token and 'type': 'access' will be set in the decoded dictionary
• If the fresh claim doesn't exist in a token, it will be marked as a non-fresh token and 'fresh': False will be set in the decoded dictionary

Many thanks to @acrossen for making this release possible!

3.13.1

• Include tests in MANIFEST.in (#197)

3.13.0

• Add support for custom encode and decode keys (#91). There are now two new callbacks that can be registered: decode_key_loader and encode_key_loader. The decode callback is passed in the unverified JWT claims, and must return a string that will be used to decode and verify the JWT. The encode callback is passed in the identity (as passed in to the create_access_token or create_refresh_token functions) and must return a string that will be used to encode a JWT. If unset, the JWT_SECRET_KEY, JWT_PUBLIC_KEY, or JWT_PRIVATE_KEY will still be used as appropriate.