This article series consist of two parts, first is theoretical and the other is practical in C#. Before saying what is JWT, to begin with, explanation of why JWT is needed or used is better off since it is a sort of my personal learning way on which whys are followed by whats. I try to be so simple while explaining the terms, but considering the following quotation from Leonardo Da Vinci that

"simplicity is the ultimate sophistication."

Why do we require JWT?

To put it simply, if the server is not supposed to store information to identify who is who(=authorization) and whereby a decision should be taken to determine the user has a privilege to access resources on the server(=authentication), JWT is ready to play.

Let's imagine that there is an overwhelming business to be carried out, requiring two or more servers. The servers are decided by NLB to progress. What if the information for both authorization and authentication stored in or doesn't exist in just one of them? What if the NLB choose that server which has no any stored information about the arrival? Some dear solutions are inevitable, such as equalizing information at once or obtaining a common storage.

Where is it used?

It conceptually can be used where authorization and authentication are matter of. However, it is used widely used in APIs.

What is the relishing use case?

There is one server where a user is logged in, SERVER1, which redirects you to another server SERVER2 to perform some kind of operation.

SERVER1 can issue you a JWT authorizing you to SERVER2. Those two servers don’t need to share a session or anything to authenticate you. A similar use case can be found here as well.

What do authorization and authentication stand for?

Authentication = username/e-mail + password (who you are), [basically this can be, but not always, e.g. HTTP Authorization header carries authentication information]

Authorization = permissions (what you are allowed to do)

What are token and JWT?

A token is a string of data that represents something else. JSON Web Token (JWT) is an 'open standard'.

It defines a compact and URL-safe way to securely transmit information as a JSON object between parties. A JWT is often used to secure RESTful APIs because it can be used to authenticate a client that wants to access the APIs.

From, IBM

🔪🔪Let's scrutinize JWT🔪🔪

JWT's structure can be kept in mind such that there are two dots, three parts.

It mainly comprises following three parts that

• JOSE header.
• JWS payload.
• JWS signature/encryption data.

There are reserved name/value pairs which can be found here with their explanations.

JWTs can be encoded in a compact representation known as 'JWS/JWE Compact Serialization'.

The header part

In this part, a signing algorithm is specified in alg which is the only compulsory parameter. It is set to the value none for unencrypted JWTs.

Some signing algorithms use a secret key known by both the issuer and the party that verifies the JWT. Other algorithms use a public and private key. The private key is known only to the issuer, while the public key can be shared in many places. The public key can be used to verify the signature, but only the private key can be used to create the signature. This is more secure than a shared key secret because the private key only needs to exist in one place.

{
  "alg": "none"
}

The payload part

The payload contains claims. This information is typically used by the server to verify that the user has permission to perform the action they are requesting.

There are no compulsory claims for a JWT, but overlaying standards may make claims mandatory. For example, when using JWT as bearer access token under OAuth2.0, iss, sub, aud, and exp must be present.

The signature part

Whatever algorithm is chosen in the header part, it is needed to encrypt the first two parts of JWT with that algorithm, base64(header) + '.' + base64(payload)

The party generating the JWT signs the header and payload with a secret key that is known to both the issuer and receiver, or with a private key known only to the sender. When the token is used, the receiving party verifies that the header and payload match the signature.

Actually, this part is to ensure that the token has not been altered after it was signed by the issuer.

Happy to see you here (: I think to show it in a practical manner by C# soon.

Soner