Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I refer to this excellent article which speaks of amazon like security for web service. However I was asked a question in the team of why do we need it if we already use HTTPS. I was unable to answer as it really seems to me they may be right although gut tells me otherwise.

Also is there places when providing REST services where HTTPS may not work? Like 3rd party websites?

If anyone has experience in securing Web Services over the public interwebs please shed some light with your experience.

Thanks in advance.

EDIT: To clarify I am not speaking of user authentication but more of client authentication. The user authentication can be assumed to be plain text over HTTPS+ REST.

My worry is that this still allows anyone to use the web service without my client to access it since everything is plai text although over HTTPS the client end point can still use my web service without the client application.

share|improve this question

migrated from Jun 13 '11 at 6:03

This question came from our site for professional and enthusiast programmers.

Best suited for – jweyrich Jun 13 '11 at 2:04
maybe you are right but my question is mor deve related. – Vangel Jun 13 '11 at 2:49
up vote 6 down vote accepted

Why do we need to give Gmail — or any other site with user accounts — our username and password if it's already using HTTPS? The answer is the same as the answer to your question.

HTTPS provides, first and foremost, an encrypted connection between the server and the client.

The trust inherent in HTTPS is based on major certificate authorities that come pre-installed in browser software (this is equivalent to saying "I trust certificate authority (e.g. VeriSign/Microsoft/etc.) to tell me whom I should trust").

Unless the server gives each user a certificate, the server can't trust the client without some other method of authentication.

share|improve this answer
sorry you misunderstand or i wasn't clear. Amazon APi docs state that we should use HTTPS but if we dont THEN we Sign the request. The username password is irrelevant at this point. – Vangel Jun 13 '11 at 2:50
At a high level, you need to prove your identity to the server in order for it to accept commands from you. Client authentication can be done via HTTPS, and it can also be done using message signing. – Matt Ball Jun 13 '11 at 2:59
so we dont need both? if I have HTTPS on the server and only allow HTTPS can i expose the web service as is without requiring any additional checks save for the username and password? Thanks for your responses I am getting a better idea now – Vangel Jun 13 '11 at 3:19
If you want to use HTTPS for client authentication, you need to issue each user a public key certificate, as described in the last link in my answer. Think of these certificates as the electronic version of a passport. – Matt Ball Jun 13 '11 at 3:44
You link for "give each user a certificate" kidn of answers my question. I guess the whole private public key and signing is still required to properly secure both ends in a web service so an SSL on the server is not enough. Your answer is the closest thus far. thank you very much. – Vangel Jun 13 '11 at 9:50

HTTPS is very good at preventing eavesdropping and "man in the middle" attacks. As it encrypts all traffic for a session.

But as most people are using the default certificates which came with their browser and have no idea how to create their own personal certificate or configure the browser to use it.

This makes HTTPS pretty useless for user authentication other than protecting an authentication dialog from eavesdropping etc.

share|improve this answer
I think you are very close to what I am asking. So you suggest we should still sign the request on the client side even if we use HTTPS? – Vangel Jun 13 '11 at 3:20

HTTPS is about securing the channel, not proving who the caller is, or the many other things you need to consider. Authentication, authorization and transport layer encryption are only a small part of what you need to consider. Many of the known vulnerabilities relating to web applications apply very much to REST apis. You have to consider input validation, session cracking, inappropriate error messages, internal employee vulnerabilities and so on. It is a big subject.


share|improve this answer

You can take the approach of client SSL certificates and separate the security from api. The big downside for this approach is the operation overhead which will get expensive as more and more clients consume your api.

At any rate, HTTP basic authentication is just fine for vast majority of publicly consumed services.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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