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.
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.
I confess that I did not delve that deep into the specification, but I don’t think that’s meant to be supported. According to this answer in SO including two Authorization headers is not meant to be supported (the answer is from an author of the spec so lets take this one as granted).
It could be argued that the above question is for multiple headers and you’re asking for a single header with multiple schemes as list of values. For this case, I think the above answer also suggests it should not be supported as per one of the follow-up comments.
As a curiosity, I quickly looked at the spec which states:
Without going for all the details it seems auth-scheme is only meant to be provided once so the syntax and scenario you mentioned does not seem to be formally supported.
In addition, you mention that the use case revolves around proxied calls so maybe the use of the Proxy-Authorizationheader is more adequate.
I had read the SO post you referenced. I agree that what I’m talking about is one header with multiple schemes, sorry for the confusion. I’ve added a little more information to the question, and corrected the title.
If I understood correctly the first API being called requires bearer tokens and is using Auth0; this is in turn may need to call a third-party API using basic authentication and the basic authentication credentials required are from the end-user and not service credentials. This is a bad place to be, because now your API will handle user credentials that are owned by another service (as a user I would be really suspicious of this). Nonetheless, if you receive credentials for another service from the user why can’t you receive them in a different way other than an Authorization header?