Understanding OpenID Connect JWT Signing and Asymmetric Encryption

I have worked with OAuth and OpenID Connect a few times in the past, but a recent discussion brought to light that I didn’t really understand how it all worked.  It was surprisingly difficult to hunt this down online, so I thought I would compile my research for anyone that is interested!

Quick intro to JWTs and encryption:

A JWT has the format {base64(header)}.{base64(payload).signature

With symmetric encryption, every client and the token provider have a shared secret, which is used to hash the payload into a signature. Clients calculate the signature of the payload and verify the signature matches.

With asymmetric encryption, the token provider keeps a private key and publishes a public key. The token provider hashes the payload and encrypts the hash into a signature. Clients use the public key to decrypt the signature and verify that matches the hash of the payload.

The following attempts to explain how an OpenID Connect token provider digitally signs auth tokens, and how a consumer can validate that token with only a public key.

*Note all numbers used here will be very small, in reality, these numbers will be very large prime numbers, which is what makes this algorithm powerful.

1. Token provider generates two keys, one private and one public

(don’t get hung up on where these numbers come from, you can read more about it in the link at the bottom)

1. Starts with two prime numbers 7 and 13
2. Multiply to get 91
3. Choose another number, 5
4. Pass 7, 13, and 5 into an algorithm to get 29
5. The results of these operations determine your keys:
1. private key = [29, 91]
2. public key = [5, 91]
1. When signing a token, the provider
1. takes the token payload, for example:

{

"sub": "1234567890",

"name": "John Doe",

"iat": 1516239022

}

1. hashes them into a number: 34 (keeping this small for simplicity)
2. Then passes this number as well as the numbers from the private key into an encryption algorithm such as RS256 which does something along the lines of:
1. 34^29 % 91 to give you a digital signature = 62
3. This digital signature is then appended to the token contents and sent to the requester

1. The token requester then receives the digitally signed token and validates by:

1. Getting the public key from token provider

Note: this can be done at any interval and does not need to be performed on every token validation

1. Passing token signature and public keys into another algorithm:
1. 62^5 % 91 to give same hash value of 34
2. 34  matches the hash of our token!
2. The client knows that the token contents match the contents when it was signed and therefore it can be trusted. If the result did not match, then the requester would know that the token contents had been altered since it was signed.
1. When dealing with larger numbers, it is computationally extremely expensive to calculate a private key from a public key due in large part to the use of the modulus operator as well as large prime input numbers.  This is how token providers are able to publish their public keys and still be secure.

Feel free to reach out with correction, questions, comments!  I’m not claiming to be an expert :)

For a deeper dive into the algorithm and explanation of how the keys are generated:

https://www.tutorialspoint.com/cryptography/public_key_encryption.htm

Another explanation of this process: https://hackernoon.com/how-does-rsa-work-f44918df914b?gi=45cb57ae12fe

A really useful tool for parsing JWT tokens and understanding their structure:

https://jwt.io/

Special Thanks David Logsdon for his help putting this together!