This sounds like a database. Or if that's too slow for you, a Redis cache.
I try not to make blanket statements about software infrastructure, because we all work on a variety of systems. However, I'm having a hard time thinking of scenarios where session cookies are too hard or too slow.
If the receiver trusts the signer, they can use the data. Sometimes the two systems cannot share a database, or a cookie.
Like everything else, JWT is sometimes used inappropriately.
And of course it's not the only way to pass signed data between two systems. Sometimes it makes sense to create your own equivalent that supports only the pieces you need.
One popular criticism (and historical security risk) of JWT is that the spec allows signing algorithm flexibility. This is easily mitigated, but of course any tool that can be used improperly, will be, by someone.
But honestly, JWT is straightforward, simple, and has good library support across all popular languages. It's a good choice for an API that you expose to groups outside your organization.
The problem lay in 1. implementations blindly accepting the value in the alg field as sent by the client and 2. one of the allowed "algorithms" was 'none'. An attacker could create a JWT with the desired data and "alg" : "none" and the flawed implementations would then "validate" the data by applying "none" to verify the signature was "".
Oh, and the spec required conforming implementations to accept "none".
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
And most implementations did not include "none" in the default accepted algorithm list.
But yeah, the optics of that debacle were poor. And I can sympathize with those who instinctively avoid JWT due to concern that there are other design/spec flaws lurking.
(JWT is so simple though -- it's what you'd design if you designed a thing for signed, base64'ed messages and then added a couple of extra fields. Some people will respond: "So then do that instead!". :)
IMO, as long as you think of JWT as a simple and standardized signed message format, with broad cross-platform support, it's perfectly suited for its purpose.
There's lots of possibilities for signed messages to simplify some things that are complicated if tied with maintaining session state on a server.
One header chunk, one data chunk, one signature chunk. Base64-encoded and concatenated. Done.
You don't need a JWT library, although I guess I'm taking JSON parsing ability as a given. This seems reasonable -- anywhere JWT would make sense, JSON is likely established.
Some of the other associated standards (JOSE, JWKS, etc) can get complicated, but JWT is about as simple as it gets.