actually you can just never send the header and always assume that the header is `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9`
{
"alg": "HS256",
"typ": "JWT"
}
(or whatever algorithm you wish)
of course only "internal" clients would understand the jwt that isn't according to the spec.
You can do that, but you carry a risk of someone developing an internal client one day that does actually trust the remote header, because they're using an off-the-shelf library. At just about everywhere I've worked, there have been efforts to do some sort of new implementation of a client to existing APIs, either because a new language / framework got cool since the API was originally designed, or simply because there's also a new server but you need backwards compatibility with old servers (The only exception I can think of is a brand-new startup.)
"JWT, but you must roll your own implementation to avoid security risks" is strictly more dangerous than "Our custom signing system," because at least with the custom signing system, people are going to read your spec and not JWT's.
well you can use most JWT libraries with alg: none but specify the alg (so not none alg) it still is against the spec, but it works in over 70% of all libraries.
(or whatever algorithm you wish) of course only "internal" clients would understand the jwt that isn't according to the spec.