auth.md

I built this service rendered over HTTPS.

We're using the Hawk protocol to authenticate message producers, but since the service will use HTTPS, Hawk is an overkill in my opinion.

Some of the drawbacks of using Hawk in my opinion:

1. Signs whole message: overkill when you're using TLS
2. Tries to be stateless on the server-side and implements a sort of message non-repeatability by including a timestamp inside the message. The timestamp has to be equal to the server-side time take or give 1 minute. This imposes time synchronizatin between client and server, which is hard to enforce.

Goals:

1. To authenticate the producer of the message. (message is an HTTP request to the API).
2. Do not compromise the user identity if a message gets leaked.
3. Try to use a standard so that client-side libraries in different languages can be used.

Here are some solutions to provide the main goal:

1. Send username and password on every message

Cons:

The user password can be easily leaked like this: the password can be leaked into a log file or a notification service, forever compromising the password and the user identification.

2. Send an API key

Generate an API key for each user. User appends the API key to every message.

Cons:

The key is a shared secret that is sent over the wire. In this case, the key acts as a password. If key is leaked somehow, the user identification is compromised forever.

3. Use a secret key and signed nonce

The user has a secret key, which he uses to sign a nonce value (a nonce is a unique value that is generated once for each message). The message contains the user ID, the nonce and the signed nonce.

The server then extracts the private key from the user id which he uses to sign the nonce and compares it with the signed version of the nonce contained in the message. If both match, user is authenticated.

Pros:

1. The message does not leak the key.
2. Bonus: If the server stores the nonces and checks to see if the nonce has been used before, the message is not repeatable. Even if the message is somehow leaked (in log files or into a notification service), that message is not reusable.

Cons:

1. Does not authenticate the whole message. But since we're using TLS, TLS certifies message integrity.

4. Secret key signing whole message

Signing occurs in the whole message, which is what Hawk does, but is an overkill when using TLS.

Discussion

1. Am I overlooking an important aspect?
2. Given that we're using TLS, I think that the best solution here is nr. 3 or a variation on it. If you agree, then the question comes: what standards exist for implementing this?

my 2 cents:

With tls there is no benefit from using hawk.

I'd be inclined to used API keys which could be produced in a special endpoint that works with username and password (Basic Auth).

For increased security you can have API keys that expire after some time.

I like how the GH Api works: http://developer.github.com/v3/#authentication

It's always https, you can use:

• basic auth - curl -u "username" https://api.github.com
• api token sent in header - curl -H "Authorization: token BEARER-TOKEN" https://api.github.com
• api token sent in qs - curl https://api.github.com/?access_token=BEARER-TOKEN

You can even use basic auth to generate tokens! - I know this link talks about OAuth but you can ignore that. OAuth is just a dance to exchange a private key (for signing) or a token (to be sent plainly like in this case).

@soarez, thanks for the response!

Yup, this is a nice scheme, but I'm afraid that leaking a message may compromise the user, but this scheme is definitely easier for the API consumer...