A jwt, or JSON web token, is a randomly generated string of characters that is created on the server side of a web application and passed to the client side. The creation of a jwt is typically triggered by a user logging in by providing their correct username and password or by the creation of a new user. On subsequent requests to the creation or login of a user the jwt is passed from the client side back to the server where it is validated. Only then can the client access the requested resource from the server.
All well and good, but what’s the point? Isn’t a jwt only as secure as the username and password that generated it? The answer is yes. It is a common misconception that jwt’s somehow provide an added layer of security to http requests sent by legitimate credentials-holding users. This isn’t quite true.
Where jwt’s really shine is in the digital signatures that are used to verify them. I mentioned above that jwt’s are generated randomly but this is only partially true. There is an element of randomness in their creation (which gives them their security) but they are actually created using specific and standardized algorithms. Without getting too much into the details, a jwt can be thought of as a dependent variable that relies on a mix of constants and other variables for its value.
**jwt** = algorithm(secret + payload)
In the expression above, just think of the algorithm variable as being distributed mathematically across the variables in the parenthesis. In effect, we are using the distributive property as an extremely simple example of an algorithm. Notice here, that if any of the variables inside the parenthesis change, the value of the jwt will change. The jwt is validated by running the algorithm on the values in parentheses. In most use cases the payload is equivalent to user data obtained from the client, and the secret is an arbitrary value that is generated on the server. This means that unless exact values for the secret and the payload are known, the jwt cannot be replicated, and because the secret key is arbitrary and exists in a secure location on the server, it is extremely difficult to compromise a jwt unless the jwt itself is stolen.
Ok but how does this help us? Have you ever trusted someone? So much that you are inclined to trust someone that they trust? This is where jwt’s come in. Let’s say you are using a web service like Google and (let’s pretend) you trust them. You want to try another completely different web service (let’s call it Company B) but aren’t sure if they will protect that password that you use for everything. You scroll down and notice that they have an option to sign in with Google. Perfect. What this means is that Google and this other software company have a shared secret key that they use to allow authentication. When you log into your google account, Google sends the resulting jwt to Company B. Company B and Google both have access to the secret, so all Company B has to do to determine that that jwt is actually from Google, is run the algorithm on the shared secret and payload and check if the resulting jwt is the same as the one that they received.
The result is that you are now logged into Company B without ever giving them a username and password. All they have access to is the jwt that Google sent them, and the shared key. This allows you to log into a wide range of software services while still minimizing the number of servers that your confidential information exists on.
Sources:
https://developer.okta.com/blog/2018/06/20/what-happens-if-your-jwt-is-stolen
Top comments (3)
JWT is not random, not even sorta. If it was random you could never decode the token to data you can use. JWT is encoded using cryptographic operations. Because of the symmetric or asymmetric cryptography you can decode the content.
The login method used by Google is not JWT based but rather OAuth2.
Just trying to understand better. If there were no element of randomness involved at all wouldn't the jwt be the exact same every time a user logged in?
If you do not change the payload the token will be the same every single time. A good reason to not have a JWT token that doesn't have an expiration.