Why does Auth0 token authentication fail when there are multiple authentication header schemes? It seems like the spec supports it. I’m using .Net
JwtBearerAuthentication for my API. The situation I’ve found myself in, is that I need to proxy some calls through to other API’s. Those API’s require Basic authentication, so I want to send a header that has Bearer and Basic authenication. They get put into the
Authorization header as comma separated values. The issue is that Auth0 returns an error:
Authorization has been denied for this request.
Until I remove the Basic authentication header, but then I can’t get into the API that I’m proxying too.
Any ideas? My header looks something like this:
Authorization: Bearer eyJWTByTh...RUSJ9.eyJpc3MiOiJo2xw_Ew,Basic Zr237s...==
The portion of the spec I’m referring to is https://tools.ietf.org/html/rfc7230#section-3.2.2. It seems from that that if you have a Basic and Bearer schema the correct one should be picked up and utilized as the message is passed along.
It seems to me this must be a common issue. Imagine that you use a third party API over which you have no control, and it’s not CORS enabled, so you have to call it from your server side code. It requires Basic Auth, but you want to secure all of your endpoints, including this one with a token. How do you accomplish that?
As far as I can tell there are three possible answers.
Don’t secure your endpoint… if
CORS isn’t on on your server, you
should be the only one able to
call it from client side code.
Use a custom header. However this only works if you can unravel
it. If I used X-Auth: Bearer token…, how would I pick that back up server side when using Auth0?
Pass the access token in the URL, and basic auth on the header.
This also would require Auth0 support, which from the docs looks
like it isn’t supported.