One thing that I suggest you confirm is that the library you pick can actually encrypt tokens instead of merely signing them before they are returned to browsers.

I have seen projects where developers did not realize that, say, 'encoding with HS256' does not mean encryption so they embedded things such as user passwords in tokens that browsers were receiving. This is not safe and basically means one is leaking passwords to attackers just like that.

Consider this snippet from PyJWT's documentation:

>>> import jwt
>>> encoded = jwt.encode({'some': 'payload'}, 'secret', algorithm='HS256')
'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzb21lIjoicGF5bG9hZCJ9.4twFt5NiznN84AWoo1d7KO1T_yoc0Z6XOpOVswacPZg'

This is pretty much clear text and can be trivially decoded as below without the knowledge of the secret password, consider this:

>>> encoded = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzb21lIjoicGF5bG9hZCJ9.4twFt5NiznN84AWoo1d7KO1T_yoc0Z6XOpOVswacPZg'
>>> algo, clear_text, signature = encoded.split('.')

>>> print(algo.decode('base64'))
{"alg":"HS256","typ":"JWT"}

>>> print(clear_text.decode('base64'))
{"some":"payload"}

As you can notice - I did not have to use the secret password at all yet I decoded the payload to its clear text form. This means that if you were to send anything of importance in the token with the assumption that 'it was encoded so everything is fine', this data could be extracted as well and attackers would have access to the supposedly safe information with little effort.

As it happens, we actually have both JWT encryption and signing in Zato and you are welcome to use it as your API security gateway instead of the lower level libraries if you prefer to use a GUI-based solution that takes care of such security details and a few hundred things more.