100% found this document useful (1 vote)
232 views8 pages

5 Easy Steps To Understanding JSON Web Tokens (JWT)

1) JSON Web Tokens (JWT) are composed of a header, a payload, and a signature. The header and payload contain JSON objects that are encoded and joined with a period. The signature is then generated by encoding the joined header and payload using the algorithm specified in the header. 2) As an example, an authentication server can generate a JWT containing a user's ID in the payload after they login. It sends the JWT to the user, who can then send it to an application server with API requests. The application server can verify that the JWT was issued by the authentication server to authenticate the user. 3) To create a JWT, one specifies the header containing the token type and signing algorithm

Uploaded by

Abhilash Tiwari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
100% found this document useful (1 vote)
232 views8 pages

5 Easy Steps To Understanding JSON Web Tokens (JWT)

1) JSON Web Tokens (JWT) are composed of a header, a payload, and a signature. The header and payload contain JSON objects that are encoded and joined with a period. The signature is then generated by encoding the joined header and payload using the algorithm specified in the header. 2) As an example, an authentication server can generate a JWT containing a user's ID in the payload after they login. It sends the JWT to the user, who can then send it to an application server with API requests. The application server can verify that the JWT was issued by the authentication server to authenticate the user. 3) To create a JWT, one specifies the header containing the token type and signing algorithm

Uploaded by

Abhilash Tiwari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

5 Easy Steps to Understanding JSON Web


Tokens (JWT)
Mikey Stecky-Efantis Follow
May 16, 2016 · 7 min read

In this article, the fundamentals of what JSON Web Tokens (JWT) are,
and why they are used will be explained. JWT are an important piece in
ensuring trust and security in your application. JWT allow claims, such
as user data, to be represented in a secure manner.

To explain how JWT work, let’s begin with an abstract de nition.

A JSON Web Token (JWT) is a JSON object that is


de ned in RFC 7519 as a safe way to represent a set
of information between two parties. The token is
composed of a header, a payload, and a signature.

Simply put, a JWT is just a string with the following format:

header.payload.signature

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 1/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

It should be noted that a double quoted string is actually considered a valid


JSON object.

To show how and why JWT are actually used, we will use a simple 3
entity example (see the below diagram). The entities in this example
are the user, the application server, and the authentication server. The
authentication server will provide the JWT to the user. With the JWT,
the user can then safely communicate with the application.

How an application uses JWT to verify the authenticity of a user.

In this example, the user rst signs into the authentication server using
the authentication server’s login system (e.g. username and password,
Facebook login, Google login, etc). The authentication server then
creates the JWT and sends it to the user. When the user makes API calls
to the application, the user passes the JWT along with the API call. In
this setup, the application server would be con gured to verify that the
incoming JWT are created by the authentication server (the
veri cation process will be explained in more detail later). So, when
the user makes API calls with the attached JWT, the application can use
the JWT to verify that the API call is coming from an authenticated
user.

Now, the JWT itself, and how it’s constructed and veri ed, will be
examined in more depth.

Step 1. Create the HEADER

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 2/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

The header component of the JWT contains information about how the
JWT signature should be computed. The header is a JSON object in the
following format:

1 {
2 "typ": "JWT",
3 "alg": "HS256"
4 }

In this JSON, the value of the “typ” key speci es that the object is a
JWT, and the value of the “alg” key speci es which hashing algorithm is
being used to create the JWT signature component. In our example,
we’re using the HMAC-SHA256 algorithm, a hashing algorithm that
uses a secret key, to compute the signature (discussed in more detail in
step 3).

Step 2. Create the PAYLOAD


The payload component of the JWT is the data that‘s stored inside the
JWT (this data is also referred to as the “claims” of the JWT). In our
example, the authentication server creates a JWT with the user
information stored inside of it, speci cally the user ID.

1 {
2 "userId": "b08f86af-35da-48f2-8fab-cef3904660bd"
3 }

The data inside the payload is referred to as the “claims” of the token.

In our example, we are only putting one claim into the payload. You can
put as many claims as you like. There are several di erent standard
claims for the JWT payload, such as “iss” the issuer, “sub” the subject,
and “exp” the expiration time. These elds can be useful when creating
JWT, but they are optional. See the wikipedia page on JWT for a more
detailed list of JWT standard elds.

Keep in mind that the size of the data will a ect the overall size of the
JWT, this generally isn’t an issue but having excessively large JWT may
negatively a ect performance and cause latency.

Step 3. Create the SIGNATURE


The signature is computed using the following pseudo code:

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 3/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

// signature algorithm

data = base64urlEncode( header ) + “.” + base64urlEncode(


payload )

hashedData = hash( data, secret )

signature = base64urlEncode( hashedData )

What this algorithm does is base64url encodes the header and the
payload created in steps 1 and 2. The algorithm then joins the resulting
encoded strings together with a period (.) in between them. In our
pseudo code, this joined string is assigned to data. The data string is
hashed with the secret key using the hashing algorithm speci ed in the
JWT header. The resulting hashed data is assigned to hashedData. This
hashed data is then base64url encoded to produce the JWT signature.

In our example, both the header, and the payload are base64url
encoded as:

// header
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

// payload
eyJ1c2VySWQiOiJiMDhmODZhZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYw
YmQifQ

Then, applying the speci ed signature algorithm with the secret key on
the period-joined encoded header and encoded payload, we get the
hashed data needed for the signature. In our case, this means applying
the HS256 algorithm, with the secret key set as the string “secret”, on
the data string to get the hashedData string. After, through base64url
encoding the hashedData string we get the following JWT signature:

// signature

-xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 4/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

Step 4. Put All Three JWT Components


Together
Now that we have created all three components, we can create the
JWT. Remembering the header.payload.signature structure of the JWT,
we simply need to combine the components, with periods (.)
separating them. We use the base64url encoded versions of the header
and of the payload, and the signature we arrived at in step 3.

// JWT Token
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJiMDhmODZ
hZi0zNWRhLTQ4ZjItOGZhYi1jZWYzOTA0NjYwYmQifQ.-
xN_h82PHVTCMA9vdoHrcZxH-x5mb11y1537t3rGzcM

You can try creating your own JWT through your browser at jwt.io.

Going back to our example, the authentication server can now send this
JWT to the user.

How does JWT protect our data?


It is important to understand that the purpose of using JWT is NOT to
hide or obscure data in any way. The reason why JWT are used is to
prove that the sent data was actually created by an authentic source.

As demonstrated in the previous steps, the data inside a JWT is


encoded and signed, not encrypted. The purpose of encoding data is
to transform the data’s structure. Signing data allows the data receiver
to verify the authenticity of the source of the data. So encoding and
signing data does NOT secure the data. On the other hand, the main
purpose of encryption is to secure the data and to prevent
unauthorized access. For a more detailed explanation of the di erences
between encoding and encryption, and also for more information on
how hashing works, see this article.

Since JWT are signed and encoded only, and since


JWT are not encrypted, JWT do not guarantee any
security for sensitive data.

Step 5. Verifying the JWT

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 5/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

In our simple 3 entity example, we are using a JWT that is signed by the
HS256 algorithm where only the authentication server and the
application server know the secret key. The application server receives
the secret key from the authentication server when the application sets
up its authentication process. Since the application knows the secret
key, when the user makes a JWT-attached API call to the application,
the application can perform the same signature algorithm as in Step 3
on the JWT. The application can then verify that the signature obtained
from it’s own hashing operation matches the signature on the JWT
itself (i.e. it matches the JWT signature created by the authentication
server). If the signatures match, then that means the JWT is valid
which indicates that the API call is coming from an authentic source.
Otherwise, if the signatures don’t match, then it means that the
received JWT is invalid, which may be an indicator of a potential attack
on the application. So by verifying the JWT, the application adds a
layer of trust between itself and the user.

In Conclusion
We went over what JWT are, how they are created and validated, and
how they can be used to ensure trust between an application and its
users. This is a starting point for understanding the fundamentals of
JWT and why they are useful. JWT are just one piece of the puzzle in
ensuring trust and security in your application.

. . .

It should be noted that the JWT authentication setup described in this


article is using a symmetric key algorithm (HS256). You can also set up
your JWT authentication in a similar way except using an asymmetric
algorithm (such as RS256) where the authentication server has a secret
key, and the application server has a public key. Check out this Stack
Over ow question for a detailed breakdown of the di erences between
using symmetric and asymmetric algorithms.

It should also be noted that JWT should be sent over HTTPS


connections (not HTTP). Having HTTPS helps prevents unauthorized
users from stealing the sent JWT by making it so that the
communication between the servers and the user cannot be
intercepted .

Also, having an expiration in your JWT payload, a short one in


particular, is important so that if old JWT ever get compromised, they
. no. longer
will be considered invalid and can . be used.

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 6/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

If you enjoyed this article and are writing handlers for AWS Lambda
and are implementing JWT, please check out our project: Vandium

Vandium: The Node.js Framework for AWS


Lamba

One of the most exciting new cloud technologies


over the last few years has been the emergence …
medium.com

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 7/8
12/18/2018 5 Easy Steps to Understanding JSON Web Tokens (JWT)

https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec 8/8

Common questions

Powered by AI

A JSON Web Token (JWT) consists of three parts: the header, the payload, and the signature. The header specifies the type of token and the hashing algorithm being used, such as HMAC SHA256 or RSA. The payload contains the claims or the data that needs to be transmitted, typically the user information such as userID. Finally, the signature is used to verify that the sender of the JWT is who it claims to be and to ensure that the message wasn't changed along the way. This is created by taking the encoded header and payload, then signing them with a secret or private key. All three parts combined and separated by periods make up the JWT, ensuring the integrity and authenticity of the data exchanged between two parties .

Encoding in JSON Web Tokens involves transforming the data into a format that can be safely shared, using base64url encoding specifically. This process does not secure the data; rather, it structures it in a way that can be easily transmitted. On the other hand, encryption scrambles data so that only authorized parties with the correct decryption key can understand it, providing confidentiality. JWTs are encoded but not encrypted, meaning anyone can decode them and read their contents if they intercept the token, which is why JWTs should not contain sensitive information that requires confidentiality. Encoding helps ensure data authenticity rather than security .

JWT should not be used to store sensitive information because encoding and signing do not protect against data exposure if the token is intercepted. Encoding in JWT only changes the format of data for transport, and signing ensures the integrity and origin of the JWT, but neither prevents the visibility of the data contained within the token. Without encryption, any party intercepting a JWT can decode it to access potentially sensitive information such as user IDs, roles, or permissions. Therefore, sensitive data should be either encrypted within the JWT or preferably handled by other secure means to ensure confidentiality .

In JWT authentication, using a symmetric algorithm like HS256 means the same secret key is used both to sign and verify the JWT. This requires both the authentication and application servers to have access to the same key, which can be a security risk if the key is exposed. Conversely, an asymmetric algorithm like RS256 uses a public/private key pair: the private key is used to sign the JWT and remains confidential to the authentication server, while the public key can be widely distributed to the application server to verify the JWT. This setup adds a layer of security since the private key isn’t shared .

Using excessively large JWTs can lead to increased latency and decreased performance of the system. This is because larger tokens require more bandwidth for transmission, leading to slower network calls which can become significant in applications making frequent API calls. Moreover, larger JWTs also demand more processing time on the client and server sides during encoding, decoding, and signature verification operations, potentially straining resources and impacting overall system efficiency .

The verification process of a JWT on an application server involves the server using the same hashing algorithm and secret key specified in the JWT header to compute the signature of the incoming JWT header and payload. It then compares this computed signature with the signature received in the JWT. If the two match, the JWT is considered valid, affirming that it was issued by a trusted source and has not been tampered with. This process is critical in maintaining a secure system because it ensures that only authenticated requests, verified through the JWT, are processed by the server, thereby preventing unauthorized access and ensuring data integrity .

JWT can be used to assert user roles and permissions by including specific claims within the payload that denote the role and permissions associated with a user. These claims can be custom fields such as 'role': 'admin' or 'permissions': ['read', 'write'] that the application server checks when processing user requests. By embedding user roles and permissions within the JWT, applications can efficiently determine the access rights of the user, thereby making real-time authorization decisions without querying the database, improving performance and maintaining secure user interactions .

Using JWT in distributed systems offers various benefits such as stateless authentication, which reduces server overhead by eliminating the need to store session data, and scalability, as the token can be independently verified by any node without relying on a central session store. However, there are risks, including token theft, as JWTs are not encrypted; thus, they can be intercepted if not transmitted via secure channels. Additionally, the long validity of JWTs could pose security threats if not managed with expiration controls. Balancing these factors, JWT provides efficient authentication but requires careful handling to avoid security pitfalls in distributed architectures .

Adding an expiration claim ("exp") to a JWT sets a specific time after which the JWT is no longer considered valid or usable. This enhances security by ensuring that if a JWT is intercepted, it can only be used within the limited time window specified by the expiration claim. Once expired, the token cannot be used again, reducing the likelihood of replay attacks or the misuse of stolen tokens .

Using HTTPS in conjunction with JWT is crucial for secure communication because HTTPS encrypts the data in transit between the client and the server, preventing unauthorized users from intercepting or tampering with the transmitted JWT. While JWTs themselves are encoded, they are not encrypted, so without HTTPS, sensitive data from the JWT could be exposed. HTTPS ensures that even if the JWT is intercepted, only encrypted data is captured, thus maintaining confidentiality and integrity during data transmission .

You might also like