This would seem to be a “fault” of the way WordPress (the “server”) is reading the HTTP request headers. (If they are being read into an associative array without any normalisation then the comparison will naturally be case-sensitive.) This should arguably be “fixed” in WP.
However, it’s possible to create a “workaround” in .htaccess and re-create the HTTP request header with the required case. ie. Authorization (with capital A) instead of authorization (all lowercase, or whatever case is passed). However, you would need to do this for each header as required.
For example:
# 1. Save the current value in env var (Case of header name does not matter)
SetEnvIf authorization (.*) HEADER_VALUE=$1
# 2. Delete the current header (Case of header name does not matter)
RequestHeader unset "authorization" env=HEADER_VALUE
# 3. Recreate header with the required case (Case of header name is preserved)
# env=HEADER_VALUE ensures the header is only set if it was set to begin with
RequestHeader set "Authorization" %{AUTHORIZATION_VALUE}e env=HEADER_VALUE
Any comparison that Apache performs on the headers is case-insensitive, so unset’ing Authorization or AUTHORIZATION will do the same thing. As will reading the value of Authorization or AUTHORIZATION.
You do have to completely unset the header before set‘ing that header again in order to preserve the case of the required header name. edit‘ing the request header does not edit the name, only the value.
IMO it’s a bit “unusual” for these JS libraries to send all lowercase headers when HTTP header convention is to use camel-case, and let the servers canonicalise the request as necessary.