TL;DR Some header names such as Authorization have special rules about caching as well as proxy & client handling; your custom header names would not get the special behavior unless you modified every single proxy & client.
The point of using the common Authorization: <type> <value> header as defined in RFC7234 is mostly to ensure that clients & HTTP proxies that natively implement handling of those headers behave CORRECTLY.
Section 4.2 of RFC7234 says:
A proxy forwarding a request MUST NOT modify any Authorization fields
in that request. See Section 3.2 of [RFC7234] for details of and
requirements pertaining to handling of the Authorization field by
HTTP caches.
The Proxy may modify, omit, log or cache your other Authorization-* headers.
RFC7234, section 3.2 says that requests/responses Authorization header MUST not be cached (except in specific circumstances).
RFC7235, section 5.1.2, point 7 furthermore has this say to about NEW authentication schemes that use headers other than Authorization:
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., “no-store”, Section 5.2.1.5 of [RFC7234]) or response directives (e.g., “private”).
So what should you do…? If you controller both ends of the system entirely, it’s not unreasonable to define a new type value that might have multiple parameters to cover any combination of one or more token types, just avoiding the , character:
Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...
The alternative depends on server & client implementations more, and would be using a , as the alternate version list form of multiple headers:
Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...
Which depending on the server & client, may be treated the same as:
Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...
The problem here is “MAY” (lots of added emphasis) be treated the same. There’s discussions suggestion that various versions of Apache & NGINX don’t treat this consistently, and that the older HTTP RFCs are very unclear about the intended behavior.