I am building a web application and RESTful web service.

I have been reading various articles about the best way to authenticate the requests to the web service.

The best option for me seems to be to use HTTP basic authentication. Pretty much every article ive read says that authentication should be encrypted over SSL or equivalent.

Im not totally sure what this involves. Does this mean that my whole web service will have to be on a secure server? Will this slow things down?

  • A thought, cachability of data loaded over https. I'm not 100% sure on if/how this will impact.
    – user40980
    Commented Feb 5, 2013 at 16:00
  • im not sure I follow. Are you saying caching is not possible?
    – GWed
    Commented Feb 5, 2013 at 16:08
  • There are interactions between ssl/https and the webserver that may be unintended with REST - cxf.547215.n5.nabble.com/… -- I haven't delved too far into REST in a secure environment so this hasn't been an issue for me. Its more from thoughts and hints from my days as a apache admin.
    – user40980
    Commented Feb 5, 2013 at 16:14
  • Thanks. You say you haven't used REST in a secure environment. Does that mean that you arent using authentication? Or are you doing it in a different way to http basic.
    – GWed
    Commented Feb 5, 2013 at 16:24
  • Its either no authentication, basic, or ip based... and purely in an intranet (nothing facing externally).
    – user40980
    Commented Feb 5, 2013 at 16:27

7 Answers 7


First of all, try to understand how SSL (HTTPS) and HTTP authentication works.

The usual HTTP authentication methods (Digest, Basic, and any forms+cookie based authentication scheme you can implement on top of HTTP) are all insecure by themselves, because they send authentication information more or less in clear text. Whether the data is in POST fields or headers, and whether base64-encoding is applied, doesn't matter at all in this regard, the password is clearly visible to anyone with access to the network traffic. This means that HTTP authentication over an untrusted channel is worthless: all it takes for an attacker to read your password is a little network sniffing.

SSL implements a secure communication channel over an inherently insecure channel. This works, roughly, as follows:

  1. Server sends a signed certificate
  2. Client validates certificate against a list of known-good signing keys; certificate signatures can be chained, so that each node says "if the signature that signs me is good, then so am I", but ultimately, the chain needs to resolve to one of the handful of trusted authorities preconfigured on the client.
  3. Client uses server's public encryption key to send a shared secret
  4. Server decrypts shared secret using private key (because only the legitimate server has the private key, other servers will be unable to decrypt the shared secret)
  5. Client sends actual request data, encrypted using the shared secret
  6. Server decrypts request data, then sends an encrypted response
  7. Client decrypts response and presents it to the user.

Note a few important points here:

  • The certificate chain allows clients to make sure that the server they're talking to is the real one, not someone intercepting their requests. This is why you should buy a real SSL certificate, and why browsers throw scary warnings at you when you hit a site that uses an invalid, expired, or otherwise incorrect certificate: all the encryption in the world doesn't help if you're talking to the wrong person.
  • The public/private encryption used to exchange the secret makes sure that succesful communication will only work between this particular pair of client and server: sniffed network packets will be encrypted, and they will require the server's private key to get at the data.
  • Symmetric encryption is used for the bulk of the request, because it has a much lower performance overhead than private/public key encryption. The key (shared secret) is exchanged using private/public key encryption though, because that is the only way to do so in a secure way (except transporting it over a separate channel, such as a courier service).

So obviously, there is some overhead involved, but it's not as bad as you'd think - it's mostly on the scale where "throw more hardware at it" is the appropriate response, unless you're preparing for absolutely massive amounts of traffic (think Google or Facebook). Under normal circumstances, that is, typical web application usage, the SSL overhead is negligible, and consequently, as soon as you have any confidential data at all, it's best to just run everything over SSL, including resources. SSL is also the only viable way of securing HTTP traffic; other methods are simply not as standardized and thus not widely supported, and you absolutely do not want to implement these things yourself, because honestly, it's just too easy to get them wrong.

TL;DR: Yes, SSL + Basic Authentication is a good idea, yes, you need a secure server (and a valid certificate), yes, it will slow things down a bit, but no, this is not something to worry about right now.


HTTPS (SSL) isn't user authentication FYI. It just provides encryption between 2 endpoints.

But yes, there is a teeny tiny bit of overhead from it (though not enough to warrant a change in plans/hardware). See here :


  • 7
    +1 better to be too secure than not secure enough given the small overhead
    – Earlz
    Commented Feb 5, 2013 at 16:12
  • 2
    This answer is very misleading. SSL is authentication, it's just usually not user authentication. SSL authenticates that the server you are talking to is really who it says it is. (The job of the CA is to only issue certificates for facebook.com to Facebook.) Also, SSL can do user authentication with client certificates.
    – josh3736
    Commented Feb 5, 2013 at 19:11
  • @brian: I concur with josh3736. SSL does provide authentication in the cryptographic sense of the word. Without (e.g. server) authentication you are open to man in the middle attacks. SSL can provide secure client (user) authentication using smart cards or if it has authenticated the server other means (e.g. username/password) can be used over the secure channel.
    – Guy Sirton
    Commented Feb 5, 2013 at 19:46
  • Really, it was obvious the OP was asking about user authentication and not worrying about the client authenticating who they're talking to / man in the middle attacks. I edited my post in the face of severe pedantry ;) technically correct is the best kind of correct, afterall
    – brian
    Commented Feb 5, 2013 at 19:56

With HTTP basic authentication, the username and password the user provides is sent with every request to the server. This means they are in plain text even in areas of your site that don't necessarily need to be secure. Obviously, you'll want SSL here to keep your users safe.

In theory, you could use cookie authentication and only put SSL on the login page(where the username and password is sent). If your cookies are decently secure and safe against replay attacks, then an attacker wouldn't be able to do anything with them even if they did manage to get one.


Basic authentication is setting a username and password in the header of the http request. If you don't use SSL or equivalent then that username and password is sent in plain text and is trivial for anyone to steal.

Most web servers support HTTPS out of the box nowadays and although it does add overhead to every call that overhead is minimal.

You could secure some endpoints and not others (ie have an authenticate endpoint that produces a token that can be used for other calls). I would strongly recommend SSL for the whole service though as its much more secure. (if nothing else it stops sensitive data being intercepted)

  • Yeah i think that sounds like the best idea. My web application will manage the users session etc so could save the token there. But someone could still snoop the token for that session right? May still be a risk to data security
    – GWed
    Commented Feb 5, 2013 at 16:27
  • Yes generally. There are things you can do to secure cookies (ie encrypt them) but the simpler and more effective route is to secure the whole site. Unless you have a specific use case I would recommend the simplest solution Commented Feb 5, 2013 at 16:47

Jeff Atwood wrote a brief blogpost not so long ago about whether full encryption is the way to go. He describes some real-world examples and has a few lines on performance considerations too.

Also, he references this article about a Gmail case study, quoting the following:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

He also mentions some then-recent improvements to client-side caching of pages through HTTPS by the browser.

Despite this, he points out, there are other penalties, most of them being not performance but implementation costs:

  • Maintaining software quality while adding additional complexity for already busy teams,
  • Proxy caching is much harder to configure properly and needs code changes too,
  • It's hard to get security right for a mashup of content from different sources,
  • Low-end mobile devices might struggle with encryption.
  • Please expand your answer and include some highlights from the blog.
    – Walter
    Commented Feb 5, 2013 at 19:00
  • Highlights from the blog post are added. Commented Mar 6, 2014 at 17:17

HTTP basic auth without your own session handling will probably leave you open to Cross-site request forgery attacks. You can probably use it if you couple with your own session handling, but you may have trouble providing a clean "log out" function.

No matter what you use for authentication, you will need to use HTTPS to encrypt the connection (unless the web application is only accessed on a controlled, secure network). It may slow things down a bit (connection establishments are expensive, but browsers tend to keep connections for a while), but if you want a secure application, you won't be able to avoid it anyways, so you don't really need to worry about it.

Note: "HTTPS authentication" (which you mentioned in the title) is misleading - it could refer to SSL client certificate authentication, which has little to do with the text of your question and has it's own set of benefits and problems. You probably don't want to touch that.


How are you going to accomplish the basic authentication?
If it is a hard coded username/password and you are using your webserver's built in functionality to do it, it will likely have a near zero impact. If you are off doing crazy things in a database or something similar, then yes there could be an impact.

Like others have noted here, SSL & sending the extra headers will technically make things slower but it will not be significant in any way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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