In Python, the PyJWT (https://pyjwt.readthedocs.io/) library provides all the tools you need to generate and read back JWT tokens.

Once you've pip-installed pyjwt (and cryptography), you can use the encode() function and the decode() functions to create tokens.

In the following example, we're creating a JWT token using HMAC-SHA256 and reading it back. The signature is verified when the token is read, by providing the secret:

>>> import jwt 
 
>>> def create_token(alg='HS256', secret='secret', **data): 
...     return jwt.encode(data, secret, algorithm=alg) 
... 
>>> def read_token(token, secret='secret', algs=['HS256']): 
...     return jwt.decode(token, secret) 
... 
>>> token = create_token(some='data', inthe='token') 
>>> print(token) 
b'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpbnRoZSI6InRva2VuIiwic29tZSI6ImRhdGEifQ.oKmFaNV-C2wHb_WaMAfIGDqBPnOCyOzVf-JWvh-6bRQ'
>>> read = read_token(token) 
>>> print(read) 
       {'inthe': 'token', 'some': 'data'}

When executing this code, the token is displayed in its compressed and uncompressed form.

If you use one of the registered claims, PyJWT will control them. For instance, if the exp field is provided and the token is outdated, the library will raise an error.

Using a secret for signing and verifying the signature is great when you have a few services running, but it can soon become a problem because it means you need to share the secret among all services that need to verify the signature. And when the secret needs to be changed, it can be a challenge to change it across your stack securely.

Basing your authentication on a secret that you are sharing around is also a weakness. If a single service is compromised and the secret is stolen, your whole authentication system is compromised.

A better technique is to use an asymmetric key composed of a public key and a private key. The private key is used by the token issuer to sign the tokens, and the public key can be utilized by anyone to verify that the signature was signed by that issuer.

Of course, if an attacker has access to the private key, or can convince clients that a forged public key is the legitimate one, you would still be in trouble.

But using a public/private key pair reduces the attack surface of your authentication process by a lot. And, since the authentication microservice will be the only place that has the private key, you can focus on adding extra security to it. For instance, such sensible services are often deployed in a firewalled environment where all accesses are strictly controlled.

Let's see how we can create asymmetric keys in practice.