5

I'm using a token style authentication process. After the client has obtained a token, it is either set in the client's cookies (for Web) or the authorization headers of the client's requests (for mobile). However, in order to obtain a valid token, the client must first "log in" using an valid username/password combination. My question is this:

Is there any added security by sending the username/password combination in the authorization header vs. as parameters in the JSON body of the request (assuming I'm using HTTPS)?

I only need to send the username/password combination "once" per session in order to obtain the token. Do I gain anything by doing it a la "basic-auth" style?

Drew Burnett
  • 607
  • 7
  • 17

1 Answers1

8

There's no added security in sending credentials in the Authorization header vs. a JSON body. The advantage in using the Authorization header is that you leverage on the standardized HTTP semantics, and you don't have to document exactly what clients should do. You can simply point them to the RFCs.

If you're concerned about being really RESTful, I'd say using the Authorization header instead of rolling your own method is a must.

Pedro Werneck
  • 40,902
  • 7
  • 64
  • 85
  • In response to your comment about "being really RESTful": why exactly is this so? Suppose I expose an /auth endpoint which allows for both POST and DELETE requests - to create and dissolve sessions respectively. Is that an acceptable practice as far as you're aware? – Drew Burnett Apr 11 '15 at 16:29
  • 1
    @AndrewBurnett In a REST application you shouldn't deviate from the standards defined by the transport protocol, so if you're using HTTP and you need authentication, you should use some authentication method standardized by HTTP. Server-side sessions are never RESTful, so if there's a need to DELETE it after use, you're probably storing state needed to complete the request within the server, which violates the stateless constraint. – Pedro Werneck Apr 11 '15 at 20:23
  • 1
    @AndrewBurnett As for being acceptable, that's up to you. If you understand the benefits of REST, you have an API that requires them and you want to follow the REST constraints as much as possible, it's not acceptable. However, that's rarely the case. Most people adopt only a few constraints and aspects of REST and it works well for them. Purism for the sake of purism is counter-productive. – Pedro Werneck Apr 11 '15 at 20:25
  • 1
    Regarding "There's no added security in sending credentials in the Authorization header vs. a JSON body": Isn't it better send security credentials via the header as the server is able to perform authentication BEFORE processing the the request body. E.g. if the the first two parameters of the request body are the credentials and the remaining of the body contains the actual request, one could easily send very large requests to the server without being authenticated. Because the server processes the whole body first before doing the authentication. What do you think? – Theo Nov 18 '15 at 10:00
  • @Theo That's a good point. Yes, It might be an avenue for DDOS attacks, but then if you're expecting that possibility, you should have a way to detect them and shut down the source IPs even before they reach the HTTP server. – Pedro Werneck Nov 18 '15 at 12:50