Why and when should we use JSON Web Tokens?

Question

I think that https://jwt.io/ does not explain very well why or when to use JWT. It explains other things that could be ok to consider but not critical to decide whether or not to use it or why it will be handy.

My thoughts of why should we use JSON Web Tokens:

Authentication: It is useful to store the session outside the service and benefits from the stateless pros (E.g: scaling). So JWT will be handy to not have to implement a remote session solution that will demand for example a memcached infrastructure, a token manager software module to create, renew, invalidate token. But it will have the drawback that the session information will be in the client and therefore exposed.

What is not clear:

• Information Exchange: Share your secret (or a public key) in order to allow the sender to sign the token. Why not use https for this or certificates?
• Ease of client-side processing of the JWT on multiple platforms, especially mobile. But https://jwt.io/ does not explain why JWT is used at internet scale. (In my opinion is because of the stateless server).

Answer 1

So my question is: are my assumptions correct? I'm confused about when I would need to use jwt and the benefits over the current/actual solutions

You've covered the propaganda and marketing, now let's take a moment to realise what problems JWT solve.

What JWT is not

When you verify a token, you have checked that the token was well-formed only, you did not prove that the party presenting the token has any authz so JWT itself is not proof of Authz, it is proof that an identity authenticated itself and was verified to be who they claimed to be then - and the JWT was generated to represent claims that verified identity had at the time it was verified. These are claims, ergo when the JWT is presented and you checked that it was well-formed (by doing a verify check) the attributes are like saying;

I claim I have these authorisations, please authorise me

I.e. you must make sure these claims are valid!

There are default claims that have nothing to do with authz but they can tell you about how long the claimed authz should be trusted once authorised nbf and they can tell you that the authz claims apply when used for a specific purpose aud and the custom claims are where you might add application specific logic for authz that help you check permissions like group names of the user.

A JWT is

The goal is having a way to have trust in a system (party C) that assures identity and authorisation, to a party that requires these identity and authn to be trustworthy (the end-user Party A) so that they can make ACL or Authz decisions in their app (Party B).

The JWT is generated by Party C when they verify Party A is authentic. Party C is a company like Okta, Auth0, JumpCloud, Azure, GCP, Amazon (Cognito). If you issue JWT, you are not typically the same organisation as the user of the JWT.

If you are the application developer, and you need a system to provide Authz and ACL, you must have a good foundation of trustworty Identity that you know and trust has done the proper Authn checks, this is why JWT was designed.

So as the application developer you almost never need to generate a JWT, they only time you do is if your software is providing a 3rd party proof of an identity that you have checked the Authentication challenge-response for and you assure the 3rd party using the JWT you generated. An example of this is OIDC, where the identity provider is the OIDC producer that generate the JWT, and your application and your users consume the OIDC protocol and pass the JWT around to represent the identity and authn of the end-user.

So when you get any JWT you first make sure it is well-formed, then after you verify it is a valid structure you read the claims inside the JWT and apply application logic to do things with the claims, things like add your own authz and ACL logic. Because Authz can never be outsourced, it is business logic that is always 100% written into your application, and everytime you assume authz was performed by other means that is not your own code, you are actually assuming trust not assuming authz

you literally have 0% authz unless you wrote 100% of the authz logic

So JWT uses are contextual

Are you the JWT producer? therefore the purpose of the JWT you generated is to assure that you performed Authn and you assure consumers of the JWT the identity is authentic

Are you a JWT consumer? Then you must check the JWT was well-formed so the claims can be used, then you must treat the claims as claims and make sure they are verified for the use case the claims are intended in your app, and if you do not check the claims you are putting inherent trust in the requesters who presented the JWT.

If you process claims as-is and not make sure they are trustworthy, then the requester has complete control of what the app does, because the app puts blind trust and if you say you have permissions because it is in the JWT, then the app will trust you are allowed.

Fact is, a public key created the signature of a RSA/ECDSA signed JWT, a public key! so the verify proves it was well-formed when it was signed with a public key...

Do you still trust the JWT verify method?

Answer 2

To adress just the unclarities

I will use a JWT with this information (plus all the mandatory fields) in my examples:

{
  "sub": 1,
  "scope": "read-access"
}

Information Exchange: Share your secret (or a public key) in order to allow the sender to sign the token. Why not use https for this or certificates?

You share your public key so that anyone can validate that a specific JWT is signed by you. And if that anyone trust you, it can trust the JWT. For example Auth0 has signed the JWT in the example. You fetch the public key from Auth0 and can validate that the JWT sent to you was issued by Auth0 and not tampered with. If you trust Auth0, you can trust that user 1 has read access.

But it will have the drawback that the session information will be in the client and therefore exposed.

This is often not a problem that the user know its authorities. Instead it can be used to render the GUI appropriately according to the users current state. In this example you can render a "Read" button but not the "Write" button.

Ease of client-side processing of the JWT on multiple platforms, especially mobile. But https://jwt.io/ does not explain why JWT is used at internet scale. (In my opinion is because of the stateless server).

Once the user is logged in (obtained a JWT), this can be verified by any system that trusts the issuer of the JWT. This enables Single SignOn on any number of backend systems - at Internet scale.

So JWT will be handy to not have to implement a remote session solution that will demand for example a memcached infrastructure

This is not even possible if the different backends are deployed on different data centers, different regions, Lambda functions that are short lived and most other setups where a single backend server is not used.