10

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?

Improve this question

2 Answers 2

Reset to default
22

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.

Improve this answer
1
  • 3
    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.
    – Stephen P
    Nov 21, 2014 at 22:34
3

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.

Improve this answer
5
  • 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.
    – Carson63000
    Apr 2, 2013 at 20:27
  • 2
    Just thought I should mention that the "X-" has been deprecated: stackoverflow.com/questions/3561381/…
    – Matsen75
    Apr 3, 2013 at 8:21
  • Per this answer, does that mean that Amazon S3 is doing it wrong? docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html
    – Tom Lianza
    Mar 3, 2014 at 8:34
  • 4
    -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.
    – Lie Ryan
    Aug 13, 2014 at 16:06
  • 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.
    – Sören Kuklau
    Jan 5, 2021 at 9:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.