The JSON Web Token is simple, but powerful authentication method even though the size is relatively small. It contains the identity of the authenticated users but could also include user’s claims, such as roles or permissions. This way, your services (or API) will have the complete set of information, when responding to a request – who is the user and what access he has. In short, the JWT is a token, that can be used in stateless applications.
How do I create a JWT? How do I verify JWT? Is it safe?
Imagine the following. You have a user, that wants to access some protected data. You must have a way of “knowing” who is the user and does he has the rights to access a given resource. The simplest way to do this is the following:
- the user enters his username and password
- the browser sends the data to the server
- the server verifies them and returns a JWT (containing the user’s id for example)
- the browser receives the token and stores it in the local storage or session
From that point, the user can make requests to the server using that token.
Is it safe?
But I can just change the id in the token and get access to another user’s data!
No, you can’t. Yes, you can change the user’s id, but then the token will be invalid. To answer that, we should dig deeper into the way a JWT is created.
How do I create and verify a JWT?
All JWTs consist of 3 elements, divided by 2 dots representing HEADER.PAYLOAD.SIGNATURE
You can use any base64decoder for the above example and decode the header and the payload. You’ll end up with the following results:
"name": "John Doe",
Here you can see that the token’s algorithm is HS256 (you can just assume that’s what you want for now) and it’s type is JWT. The payload shows us that the subject (the authenticated user id for example) is 1234567890, the name is John Doe and the token is issued at 1516239022, which is a timestamp. And all that information is available to us, without a single call to a database.
Now we can proceed to the last part of the token – the signature. Here’s where the magic (verification) happens. That’s the string that verifies if the first two parts are forged. And to do this, when we create the token, we apply a secret to the encryption. This secret could be a string (word or a phrase) or even a certificate. Both the issuer and the verification app should have the same secret in order to create and verify the token. And finally, we encrypt the token with the proper algorithm.
base64UrlEncode(header) + "." + base64UrlEncode(payload),
Up until now, you have a JWT token containing the payload from the example above and you’ve encoded it with your secret. Now you have to verify it. How you do that? Well, when you receive the token from the request, you get the header and the payload (the first 2 elements of the token), encrypt them with your secret and if the result matches the 3rd element of the token – congratulations, you have just validated your token.
You should keep several things in mind, when you generate these tokens.
- you should always use complicated secrets or in the best case – use certificates
- don’t store sensitive information in the payload, as it can be easily decoded
- these tokens cannot be invalidated, unless you change the secret or blacklist them, but then you’ll break the stateless idea
As you learned, it’s pretty simple to create and verify a JWT. From that point many people start asking themselves questions about the security of these tokens. What should they contain? How long should a token be valid? How can I logout a user? All these questions will be answered in the upcoming articles…
I strongly recommend checking out these websites
Here you can verify or decode your tokens. Go ahead and copy/paste the example token there and see it’s content.
A useful website, where you can decode base64 encoded data.