node-jsonwebtoken | JsonWebToken implementation for node.js http | Runtime Evironment library

You didn't provide encoding options for you public and private key when generating the key pair. I don't know what the defaults are but this

When you sign a token with node-jsonwebtoken you normally just get the default header

you can aferm it with this.

You're not handling the asynchronous code correctly. The jwt.verify method returns a Promise if you do not pass it the callback method.

If you use return jwt.verify(id_token, getKey, { algorithms: ['RS256'] }) inside the do_thing function and call it like this do_thing().then((decodedToken) => console.log(decodedToken)), it should work as expected.

The way I've usually seen JWTs used, there is only a very small number of trusted issuers, often only one, and the tokens are used as bearer tokens. In many cases, the issuer and the verifier are the same. In other cases, the verifier trusts one identity provider (e.g. Google) and fetches the public key from a https URL (example).

In your case, you could act as both the issuer and verifier:

1. You (the server) would generate one key pair.
2. Your API servers would trust JWTs signed by this key (and they'd only have the public key, since they only need to verify them).
3. An authentication/management server would have the private key, would authenticate your user, and issue them a JWT.
4. The client would never handle any keys, they'd simply store the signed JWT, and pass it as a bearer token when making a client request.

This is e.g. the approach described here as the approach used by GitHub. In this case, the issuer and verifier both belong to you. This approach is the easiest for both you (you can trust the content of the JWTs once you've verified the signature), and the client (they're just dealing with an opaque API key and don't need to deal with the complexities of JWTs at all).

A possible alternative approach could be:

1. A key pair is generated and the public key is associated with the account. This can be done in multiple ways (see below), but the end result is the same: The client has a private key, and your server knows the corresponding public key and which user it is associated with
2. When making a request, the client creates a JWT, signs it with its private key, and includes their user name in the token (e.g. in the iss and or sub field).
3. Your server takes the token, extracts the user name, looks up the public key associated with the account in the database, and validates the token.

This approach is used e.g. by Google Cloud for service account authentication.

Step 1 above can be done in two ways:

• You authenticate the user, generate a key pair, associate the public key with the account, and let the user download their private key (via https of course). While it's generally considered somewhat bad form to generate keys for someone else (because you get to see a key that you don't need to know and you have to send it over the network), it's a lot easier, and Google is doing just this.
• The user generates and stores the key pair. You authenticate the user, the user uploads the public key, you associate it with the account.

Either way, if you go with the "user signs a JWT" approach, you likely will want to provide client libraries, or at least code examples. Note also Google's requirement that the tokens must be short-lived, enforced by treating long-lived tokens as invalid. Without this rule and enforcement, what will happen is that many client developers will be annoyed about your complicated solution, manually sign a token that is valid forever on his laptop, and then use it as a bearer token.

heroku login actually doesn't use JWTs at all. It retrieves and stores an OAuth Bearer Token. This is most comparable to the first approach (client never handles any private keys, just gets an opaque blob, which happens to be a JWT that you can verify). The difference between a non-JWT token and a long-lived JWT is that your API servers have to look up the meaning and validity of the regular token in a database, whereas the JWT directly tells you the user identity, and possibly permissions and other attributes that you included when issuing it.

The expiration is saved inside the CLAIM. As written in the RFC.

4.1. Registered Claim Names

4.1.4. "exp" (Expiration Time) Claim

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.

Also, take a look at jwt.io it is much easier to read than a RFC.