Custom use of Authorization header in a REST API

Question

I'm building a REST api where clients are authenticated using client certificates. A client in this case is not an individual user, but some sort of a presentation layer. Users are authenticated using a custom approach and it's the responsibility of the presentation layer to see that this is properly done (note: I know this is not the proper approach, but the api is not public).

I would like to pass the user name for each request (not the password), but I'm not sure where to do this. Would it be a good idea to use the Authorization header?

Answer 1

Using the Authorization header seems like the right thing to do. It's the entire purpose of the Authorization header.

From https://www.rfc-editor.org/rfc/rfc7235#section-4.2 :

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

If you have your own auth scheme document it, but there's no need to reinvent the wheel.

• Stephen P: It doesn't just seem like the right thing, it is the right thing. (I've been researching this all day) Section 4.1 in RFC 7235 expressly demonstrates use of a custom scheme "Newauth" in the "For instance", along with a standard scheme "Basic" allowing the client to use their choice of either scheme. That said, if you're using a "standard" scheme you should use it correctly. Zach's answer is correct and Filip's is incorrect.

Answer 2

I wouldn't recommend that you make non-standard use of a standard HTTP header. Primarily because it can be misleading to other developers that know how the Authoriziation header is meant to be used in HTTP authentication, but also to avoid any potential issues with other parts of your stack having conflicting awareness of the same request header.

Whatever the case, there's nothing preventing you to use a custom, non-standard X-Authorization-User header, specifically for your purposes.

• Carson63000: 100% agreed. If you want to do something custom, that's what the X- prefixed headers are for. If you're going to use a standard header, don't use it for anything unusual or unexpected.
• Matsen75: Just thought I should mention that the "X-" has been deprecated: stackoverflow.com/questions/3561381/…
• Tom Lianza: Per this answer, does that mean that Amazon S3 is doing it wrong? docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
• Lie Ryan: -1. As mentioned by Zach Dennis, unlike most other HTTP headers, the Authorization header is designed to be extended and there is a clearly specified way on how to define your own authorization scheme. In a nut shell, just make sure you use a custom authorization scheme name.
• Sören Kuklau: I disagree that this is a "non-standard" use of that header. The header's purpose is: "The "Authorization" header field allows a user agent to authenticate itself with an origin server". A REST API client is a user agent.