Auth: Why HTTP POST?
Recently I was asked:
“Why do we use the POST method for sending authentication requests?”
I assumed that it had something to do with security, but I didn’t know much more than that. I’d used POST for sending authentication requests in the past because that’s how I was taught. This gap in my knowledge irritated me and I decided to do a little digging into the subject; now I would like to share what I’ve gathered.
First, this article assumes that you have implemented HTTP requests in a project and are familiar with the most commonly used HTTP methods. If you aren’t, feel free to check out this article from Codeacademy.
Alright, time to dig in.
Security
Part of the answer to the question of why the POST method is considered best practice for sending authentication requests is, as I’d assumed, related to security.
At the heart of this is TLS/SSL encryption, indicated by ‘HTTPS’ in the URL. Following strong pushes from Google, among many others, TLS/SSL encryption has become almost ubiquitous. Google Chrome marks all unsecured URLs with ‘Not Secure’ even flagging some as ‘Dangerous’ if they collect information.
So what does this have to do with the method that we choose to use? In an HTTP request, different methods allow information to be sent in different ways and these ways are not equally secure.
For example, if we sent some credentials to a server using the GET method, we would have to store the information in the URL as URL/Query Parameters.
https://www.example.com/login/?username=brockstar&password=1234If we use the POST method instead, we can store the information in the request’s body.
"credentials": {
"username": "brockstar",
"password": "1234"
}Sending information in the request body is more secure than sending it as a URL/Query Parameter, but the reason for this isn’t particularly intuitive. Both are encrypted by SSL/TLS, so it seems logical that they are equally secure. But the URL could be stored in plain text by your browser (history, for example), which is a vulnerability, and it could be sent unencrypted during DNS resolution, which happens before SSL/TLS encryption, another vulnerability.
So we can conclude that it is more secure to send information in the request body instead of as a URL parameter. POST makes that possible but so do a few other methods such as PUT and PATCH. We need another reason, in addition to security, to show that the POST method should be used.
Intended Use
This other reason is that the intended use of POST best aligns with the qualities of many authentication requests.
To understand why, we need to understand what the word idempotence means in terms of HTTP requests. This word sufficiently intimidated me when I first saw it but, in concept, it’s pretty simple.
Simply, a request method is idempotent if the effect following multiple requests is the same as a single request. For example, a PUT request is intended to be idempotent because updating any existing content should always result with the same change, regardless of how many times that request is made.
//----
// 1st RequestPUT /users/12345678
Content-Type: application/json"{"name": "Bill"}// Result:
// User 12345678 has its name changed to "Bill"//----
// nth RequestPUT /users/12345678
Content-Type: application/json"{"name": "Bill"}// Result:
// User 12345678 has its name changed to "Bill"
// even though the user's name is already "Bill"
// This will always have the same effect.
Something that really sets POST apart from other HTTP methods is that it doesn’t need to be idempotent. Its intended use is for any non-idempotent HTTP requests like, for example, creating new records in a database.
Because authentication requests often include the creation of a record, like a session, they are often non-idempotent. Logging in could also refresh the time that a user should remain logged in for, or have other side effects if they are already logged in, which have different effects and are, therefore, non-idempotent. So POST, intended for non-idempotent requests, best fits most authentication implementations.
Conclusion
In summary, the HTTP method most often used for authentication is POST because it allows authentication information to be sent through the more secure request body and because authentication requests are often non-idempotent which best fits the intended use of POST.
I hope that this provided an opportunity for any readers to deepen their knowledge on this subject. I learned a lot in researching this question and am endlessly learning more. Thank you for taking the time to read and have a wonderful day!
—
I would love feedback from anyone who can contribute to, or contradict, the contents of this article. It’s possible that I misunderstood some of the concepts that I read about.
—
Most of my information came from the following places:
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Stack Overflow: What method should I use for a login (authentication) request?
