How does a server verify a JWT? Where does the Public Key come from?

4
votes

I am looking at the examples of JWT tokens in Node.js, and the verify function. My question is, where does this publicKey come from in verify(token, publicKey)? What is the flow?

The client (one of my users) has a client library installed on their computer/server, for making requests to my app myapp.com. In the myapp.com server, I call verify(token, publicKey). In the client library I generate the token using privateKey. The question is, how does the client get this private key generally? (i.e. is heroku login downloading a private key under the hood for making JWT requests, sort of thing?). And how do you fetch the public key? My understanding is, the client would download a private key, and our server would store the public key. Then given you have the public key and token, just call verify(token, publicKey). But how do you get the public key for the token on the server generally? Is the server storing one public key per private key disseminated to the client installed libraries?

1
securityjwtpublic-key-encryption

1 Answers

4
votes

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.