You appear to be shadowbanned for no immediately obvious reason. I vouched this comment to point out that it contains a factual error, to wit, the claim that the headers and URI of a request made via TLS are sent in the clear. They are not; the socket is encrypted before any protocol messages are exchanged. Perhaps you're thinking of SMTP STARTTLS?
Companies have moved to OAuth, and to JWT as the payload, because it provides a lightweight, shared-little authentication/authorization framework that's well suited to the needs of a distributed microservice architecture and to third-party service integration - not because it overcomes a nonexistent problem with HTTPS not encrypting headers.
A properly configured SMTP STARTTLS would not really send anything substantial in cleartext either, it would issue the STARTTLS command as the first command and the rest would be wrapped in encrypted TLS. You can think of the unencrypted STARTTLS preamble as a set of static ascii bytes that are the same for every connection.
It's the closest common parallel I can find for what the prior commenter is describing, but yeah, it isn't really all that close. I've seen poor implementations leak, but not for many years now.
I don't think the op had something else in mind. IME it's a strangely widespread misunderstanding that https encrypts just parts of the http request. I think it's because of the advice to not put sensitive data in urls. The reason for that is due to logging at the endpoint, but it's misunderstood that it's not encrypted. It's funny because it's so easy to test the hypothesis, and it's hard to even propose a reason it would be that way.
Companies have moved to OAuth, and to JWT as the payload, because it provides a lightweight, shared-little authentication/authorization framework that's well suited to the needs of a distributed microservice architecture and to third-party service integration - not because it overcomes a nonexistent problem with HTTPS not encrypting headers.