Are unsecured JWTs rare in practice? Should they be?

Question

I am planning to use JSON Web Tokens for a new web application that I am developing in Angular 2. Since I haven't used it before I am reading some tutorials to understand how it exactly works. In an online resource I read that unsecured JWTs are rare in practice. I was wondering if signing and encrypting adds any extra security benefits in the following (common) use case:

I am developing an application that produces price cards / posters for a company that owns a couple of stores with consumer electronics. Basically all the users do is send a format of a price card and some formatting details to the backend. As a result, a PDF is generated and returned by the backend to my application.

This is straightforward application that has one task (I would suspect that most web applications are like this?). Why would I implement validation (signing) and security (encrypting) if this application is served over a safe TLS connection? Wouldn't it be superfluous and only make my application slower? Or is signing and encryption simply a best practice that should be implemented whenever possible?

Answer 1

TLS provides a secure encrypted channel, but does not authenticate the client (except using two ways TLS with client certificates). The web application must send in each request a proof-of-authentication: credentials or authentication token

The classic technique is asign a random identifier to tokens and maintain a list of issued tokens, that's how session-based systems work.

The main advantage of JWT over session-based systems is that it does not require server storage. Also avoids queries to the database because server can rely on token claims.

In the context of authentication a JWT must be signed so that the server can trust the content. If not, anyone who knows how the IDs are assigned could create fake tokens.

Encryption would be only needed if you want to hide the content of the JWT to client side (channel is secured with TLS), for example if contains sensitive data. Claims like subject sub, expiration date exp or issuer iss are usually not sensitive