I don't know what exactly you mean by improving performance by looking at the payload before the cost of signature verification. If you mean that for some reason you could discard large portion of messages without actually verifying the signature then this is generally false.
In a DoS situation the attacker might want to consume your resources without bothering to forge the signature but just as well he can forge the content so potentially easy fix to their fake content will cause you to pay for the signature verification anyway.
If, on the other hand, the application somehow relies on this to be viable then very likely this is a design fault. I can imagine for example that you might want to discard messages with outdated tokens but there are better ways to solve this (just don't send outdated tokens?)
If you decide things without checking with a higher authority, then you are the Confused Deputy, and that typically ends badly. It's not Barney's fault he keeps getting locked in the jail cell. It's Andy's.
You could arguably define another means of out-of-band signalling, though, but it would also be unauthenticated.
Edit: That said, getting the unauthenticated data should be very explicit and impossible to do "accidentally", if the library allows it at all.
Are you essentially talking about having different strategies to verify the token? Would it make sense to provide some sort of filter function as a parameter that the library can call to clarify what operations need to be performed?
That would allow you to peek at the records in a context where your role is clear, and where the code flow makes it awkward to take the data and run with it. If the code feels wrong enough, it's hard for the developer to claim ignorance, and if it's clear from the outset that ignorance is not an explanation, that leaves malice and stupidity. Most developers won't admit to either, but if forced they'd rather be seen as malicious than stupid, and malicious gets you a meeting with HR.
Yes, you could have side effects, but it's pretty damned obvious you're being naughty. That's mostly what I want. The obviousness of the cheating makes people think twice, ask questions. Slow down.
A lot of libraries could be better if the authors spent some time sitting at breakpoints in their own code. You could, I'm sure, arrange a JWT parser so that the data you need for triage is hanging out in a very clearly named stack frame a couple steps into the library.
In my case the format was simple enough that I trained a couple people to be able to inspect these things by hand and tell what went wrong. The happy path for the format was stupid simple. Anyone could have written their own parser for the happy path. It was the rules enforcement that made the code I had worth anything. We were the source of authority, and I took that seriously, on the Precautionary Principle if nothing else (and there were plenty of other reasons).
Well, of course I'm in charge. Last time Steve did something he pushed the big red button that shut down the whole server room. If I weren't in charge, then it would just be "Steve"s everywhere. Anarchy. Who put the red button there? Who thought having the big red button there might be a stupid idea? That's not important. What's important is that Steve fucked up and I didn't. Remember: never trust Steve.
When people sit down to write open source, they write it the same way they would write code at work, because they've either never experienced anything better, or it was drowned out by the din. So their OSS is always almost as toxic as the situation I illustrated above.
If, for some reason, you want to leave dangerous things laying around, you need way more safety interlocks than an underscore. If you should never call a function, what's the harm in making it expensive to call? Use a function name where the only reasonable interpretation of calling it is that the developer consented, with full knowledge. Make the function name 60 characters long with some colorful adjectives. Name it after the OWASP recommendation that says what a bad fucking idea it is to call this method. Giant neon lights. Fireworks. And a marching band.
Do not look into laser with remaining eye.
https://hackage.haskell.org/package/bytestring-0.10.12.0/doc...
If the symbol is not exposed, then you can't get anywhere in the neighborhood of calling it accidentally. I think if you do enough object introspection you can still get the function handle, but you could never mistake the resulting code for being anything other than farm fresh, Grade-A Cheese.
The only reason you want to look at a payload is to make decisions about it, before you can trust those decisions are rational. What I did promise them is that I would continue to try to make the checks cheaper, which we did.
Ten years later, I still trust that I made the right call. Never expose a function from a security library that gives you the data without verifying it first. You are doing violence to the user, the team, the company, possibly an entire industry.