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 :

https://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose

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)

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.

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.