What is the current standard for authenticating Http requests (REST, Xml over Http)?

Question

The standard should solve the following Authentication challenges like-

Replay attacks Man in the Middle Plaintext attacks Dictionary attacks Brute force attacks Spoofing by counterfeit servers

I have already looked at Amazon Web Services and that is one possibility. More importantly there seems to be two most common approaches:

1. Use apiKey which is encoded in a similar fashion like AWS but is a post parameter to a request
2. Use Http AuthenticationHeader and use a similar signature like AWS.

Signature is typically obtained by signing a date stamp with an encrypted shared secret. This signature is therefore passed either as an apiKey or in the Http AuthenticationHeader.

I would like to know weigh both the options from the community, who may have used one or more and would also like to explore other options that I am not considering. I would also use HTTPS to secure my services.

Answer 1

I'm not certain there is one standard. If there is it would likely be HTTP Auth, (Basic or Digest). Both of the aforementioned are pretty poor solutions.

AWS is a good example of how a "roll-your-own" auth solution could work, however, when you're talking about security/authentication, roll-your-own is usually a bad idea unless you're a security/crypto guru.

My preferred choice is actually just using Client Side Certificates. It takes care of the authentication and security process. No need for an API Key because the Cert itself identifies the client user.

Answer 2

"authentication" means: prove me you are who you say you are

"who you are" is the identity of an entity (person, computer user, software, server, etc...)

"identity" is an attribute unique to each entity (a dba would say primary key here)

so you must prove to have that unique attribute in a way or another. When the entity here is an HTTP client, then HTTP Auth is the standardized way to prove to the server its unique identity (represented by what we call a user name).

It does not bother with the security of the channel, that's what the presentation layer (ie., SSL) is for, and requires a shared secret between the parts. "Shared secret" means that both parts must know it and no one else does. This implies the two parts trust each other on not disclosing the secret or taking appropriate measures if it gets disclosed (changing the secret, for example).

HTTP as a protocol does not include other ways to do authorization and leaves that at other layers. As an example, SSL can prove the identity of the two parties without sharing a secret via the use of a public key infrastructure (certificates and certification authorities).

In the end:

• if it's ok for you to share a secret between the parties, you can use HTTP Auth for authentication and SSL to secure the channel. It's up to the parties to securely exchanging and storing the shared secret

• if you don't want to share a secret, but the parties can agree on a common trusted third party, you can speak plain HTTP and use SSL for both securing the channel and proving the identity of one or both parties using a PKI (> certificates)

• there are many other possibilities but this two are the most standard I can think of and should be compatible with most of the existing HTTP softwares/libraries/whatevers out there

• home brew systems, while technically valid, will either break accepted standards or be ad-hoc (hence non standard) systems implemented at the application layer (to solve an issue that should be addressed at another layer, bah)

There are no ways to prove the uniqueness of something without agreeing on a shared secret (and keeping it secret) or agreeing to trust someone else to take care of that uniqueness (PKI). Everything else is just implementation details.