JWT authentication Best practices and when to use it

Why a JWT Deep Dive?

working to create a JWT-based authentication system

Even if you choose a ready-to-use JWT-based Authentication solution, some coding will be required, particularly on the client but also on the server.

By the end of this essay, you'll have a thorough grasp of JWTs, as well as the cryptographic primitives on which they're built, which are utilised in a variety of other security scenarios.
You will grasp when and why to employ JWTs, as well as the JWT format to the point where you can manually troubleshoot signatures using many online / Node tools.
You'll be able to solve yourself out of a variety of JWT-related issue situations using those tools. So, without further ado, let's begin our deep dive into JWT!

Why JWTs?

The most significant benefit of JWTs (as compared to user session management using an in-memory random token) is that they allow authentication logic to be delegated to a third-party server, which may be:

-> a centralised authentication server created in-house
->Typically, a commercial product capable of issuing JWTs, such as an LDAP.
->or even a totally independent third-party authentication service like Auth0
The external authentication server can be fully independent of our application server and does not need to share any secret keys with other network elements, including our application server - there is no secret key put on our server that could be lost or stolen accidently.

What are JWTs?

A JSON Web Token (or JWT) is a JSON payload that contains a specific claim. The fundamental feature of JWTs is that we only need to look at the token itself to determine if they are genuine.Some say you should never use it.No middleman can modify a JWT once its sent.Its important to note that a JWT guarantees data ownership but not encryption.
Because JWTs contain a Message Authentication Code (MAC), we don't need to contact a third-party service or maintain them in memory between requests to check that the claim they convey is genuine (more on this later).
The Header, Payload, and Signature are the three components of a JWT. Let's take a look at each one one by one, starting with the Payload.

What does a JWT Payload look like?
The payload in this scenario contains identity information on a specific user, but the payload could be anything else in general, such as information about a bank transfer.

The content of the payload is unrestricted, but it's vital to note that a JWT is not encrypted. As a result, anyone who intercepts the token can read any information we put in it.
As a result, any user information that an attacker could directly exploit should not be included in the Payload.

JWT Headers - Why are they necessary?

The receiver then inspects the signature to confirm the content of the Payload. However, because there are many different sorts of signatures, one of the things the receiver needs to know is which form of signature to check for.
This type of technical metadata about the token is stored in a separate Javascript object that is transmitted along with the Payload.
pic

Why not to use JWTs as session tokens

However, JWTs should not be used as session tokens by default. For one point, JWT has a huge number of features and a broad reach, which increases the risk of errors by library developers or users.

Another difficulty is that because JWTs are self-contained and have no central authority to invalidate them, you can't remove them at the conclusion of a session.

To put it another way, JWTs are pretty huge. When combined with cookies, this adds a significant amount of overhead to each request.

On the client, you can save any kind of user information.
Because the JWT is signed, the server can trust the client, and there's no need to call the database to get the information you've already saved in the JWT.
When you get to the challenge of horizontal scaling, you don't need to coordinate sessions in a centralised database.

Using JWT for API authentication

1. Google uses JWT technology to allow you to authenticate to its APIs since it is so popular and widely utilised.
2. JWT is frequently used — and possibly the only good one — as an API authentication technique.

How to expire a single JWT token

What is the procedure for invalidating a single token? Changing the server secret key, which invalidates all tokens, is a no-effort solution. However, this is inconvenient for users, as their tokens may expire for no apparent reason.

One method is to add a property to your user object in the server database that references the token's creation date and time.

This value is automatically stored in the iat property of a token. You can compare the token's iat value to the server-side user property every time you check it.

Simply alter the token's server-side value to invalidate it.You can reject the token if it is older than this.

Another alternative is to build a memory-cached blacklist in your database (or, even better, a whitelist).

Using JWT to authorize operations across servers
Let's say you're logged into one server, SERVER1, and you're redirected to another server, SERVER2, to execute a task.

SERVER1 can provide you with a JWT that enables you to communicate with SERVER2.To authenticate you, the two servers don't need to share a session or anything. The token is ideal for this scenario.

Conclusion

JWT is a widely used standard for relying on signatures to trust requests and exchanging data between parties. Make sure you understand when it's best to use it, when it's best to avoid it, and how to avoid the most fundamental security risks.