I'm sort of skeptical of the idea that a bunch of people hand-rolling HMAC stuff is going to contain fewer security issues in the long term than widely-used, tested JWT libraries. Sure if they do exactly what you say here, and nothing else, that might work. But what happens when they realize they need some minor tweak to it…
That is a healthy skepticism! I definitely would not counsel people to do it with primitives in general: it just turns out that a PRF doesn't have a complicated API and HMAC is bulletproof. More or less the only design criterium that comes to mind that is critical is "don't do anything before you validate the MAC", and that design guideline is hard to break when you use the suggested approach.
Beyond that, hand-rolling JWT isn't so hard at all. When I read about some of the exploits in certain libraries, I didn't have to worry about it, as I only supported the known authority's public key in the system I was working on.
Of course, that makes the header effectively useless in practice.
There are two obvious problems with this approach to engineering:
1. You don't know what you don't know, and there is a lot to know about cryptography beyond the minimum needed to interoperate with other systems.
2. If you're engineering seriously, you know people are going to inherit your code and your design down the road, and if you're relying solely on a minimal feature set without a coherent, informed design, those people are building on sand.
It's not like he is rolling out his own crypto library. He's just rolling his own token but encrypted/signed with industry standard crypto.
It's not terrible to "roll your own JWT" if you don't actually care about interoperability. And he's right, it does sidestep a lot of issues because JWT and corresponding libraries are designed to handle far more use-cases than what he may need it for and therefore if you don't fully understand it all, you may be shipping with unsecure configuration.
If you write your own library to do it, there are strictly more things that can go wrong because at some point you're implementing a HMAC validation thingy. If you use a third party library, you're exposed to bugs that stem from JWT's design flaws even if you only allow a specific key, like the RS256 v HS256 bug I mentioned.
You are definitely right that if for some reason you must do JWT, the way to do that is to strip as much of it away as possible. In particular, if you wanted to do safe HS256-only, you'd ignore the header, decode the body and tag, and validate the tag.
To be clear, I didn't write a cryptography library... I wrote a JWT wrapper for validating JWT for the system in question. This was also before there were JWT libraries for a number of platforms. Beyond all of this, the JWT validation worked across a number of tokens generated from an alien (to the app in question) application, and rejected when it didn't validate.
Also, it was literally only validating the tag and ignoring the header... it was using an asymmetric key for signing
