I refer to this excellent article http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ 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.

  • 3
    Best suited for security.stackexchange.com?
    – jweyrich
    Jun 13, 2011 at 2:04
  • 1
    maybe you are right but my question is mor deve related.
    – Vangel
    Jun 13, 2011 at 2:49

5 Answers 5


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.

  • 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, 2011 at 2:50
  • 3
    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, 2011 at 2:59
  • 1
    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, 2011 at 3:44
  • 1
    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. Jun 13, 2011 at 9:50
  • 1
    +1 It's great you mention client certificates but it's not necessary that the server issue the certificates. They just need to be signed by a trusted CA; basically the same as how server certs work.
    – JimmyJames
    May 31, 2018 at 13:48

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.

  • 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, 2011 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.



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.


SSL is fine, but it simply isn't enough. Only one way for internet criminals to access sensitive information is to intercept the data packets flowing between the visitor and the website. Any content on a site may NOT be protected by the expected encryption if SSL is not enforced properly. So, while a secure link is suggested by the browser, some of the communications may not be secure or encrypted at all. There are also possible exploits that could disrupt this exchange of information. Examples are: MIME mis-matches Cross-site Scripting Clickjacking

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