Is there a valid alternative to HTTP headers for sending auth credentials

by ds390s   Last Updated January 20, 2018 01:05 AM

I have built simple auth for REST servers in academic projects. I always used the headers to pass the credentials. This is probably just because every tutorial I've ever seen did it this way. Initially, I'd have header fields for user and password, but I eventually switched to basic auth. Anyway, whatever it was, I always had it passed in the headers. My impression was that this was the single correct way.

I am told by the platform team at my work, that we are required to log all headers of each request received, no exceptions, and so, I should not be using headers to accept any sensitive information, such as a password. I was shown an example of a REST API built by another team. For POST and PUT methods, the auth string was accepted in the message body. For GET and DELETE methods, it was in the URL query. This seems wrong to me, but I can't exactly explain why.

I am trying to figure out if I should fight against this policy. I'd like to find out if my position is correct, and, if so, how to support it when I speak to leadership.

  • Am I correct in my thinking that HTTP headers is the single correct way to pass auth credentials in a stateless REST API?
  • Am I correct that using the URL query params is dangerously insecure, or otherwise inadvisable?
  • If I am correct, is there some authoritative source that I can reference when I make the case to my leadership? (other than RFC 7235, I've read it. It is too technical for the people I need to convince.)


Related Questions