/examples/hmac_api/README

Introduction
------------

This example shows how to make an Amazon-style HMAC authentication system for an API with mochiweb.

Purpose
-------

The purpose of this example is to:
* make it easy to implement an API in mochiweb
  - using a proven approach so that 'amateurs' don't have to reinvent crypto
* make it easy to generate client libraries for that API so that client-side implementers can:
  - reuse closely related code examples
  - build compatibility unit tests instead of fiddling around debugging their library against live implementations of the system

Scope
-----

The scope of this document is:
* a description of the client-server exchange
* a reference implementation of
  - the server-side implementation of the exchange
  - the client-side implementation of the exchange
* developing a custom implementation of an API
* deploying that implementation to new client-side users to build their client libraries

Contents
--------

Subsequent sections of this document are:
* the client-server exchange
* the reference implementation in this example
* building a custom implementation
* deploying a custom implementation

The Client-Server Exchange
--------------------------

OVERVIEW

This section describes the client-server exchange for an Amazon-style API authentication schema. It has the following characteristics:
* based on a public key/private key
* used to authenticate non-SSL api requests
* not a full once-use schema and is vulnerable to replay attacks within a short time window

TYPE OF API

The api described in this document is:
* suitable for machine-machine communication

The api described in this document is NOT:
* an implementation of 2-legged OAUTH
  - see https://github.com/tim/erlang-oauth
* an implementation of 3-legged OAUTH

It is not suitable for use in applications where an end user has to log into a service and piggy-back on top of a keypair security system.

THE CLIENT LIBRARY HERE IS **NOT** AN AMAZON CLIENT LIBRARY. AMAZON DOES FUNKY STUFF WITH HOSTNAMES AND PUSHES THEM ONTO THE URL IN CANONICALIZATION! THE CLIENT LIBRARY IS AMAZON-A-LIKE ENOUGH TO USE THE AMAZON DOCOS TO BUILD A TEST SUITE.

STEP 1

The client is issued with a pair of keys, one public, one private, for example:
* public:  "bcaa49f2a4f7d4f92ac36c8bf66d5bb6"
* private: "92bc93d6b8aaec1cde772f903e06daf5"

In the Amazon docs these are referred to as:
* AWSAccessKeyId     (public)
* AWSSecretAccessKey (private)

These can be generated by the function:
hmac_api_lib:get_api_keypair/0

This function returns cryptographically strong random numbers using the openSSL crypto library under the covers.

The public key is used as a declaration of identity, "I am bcaa49..."

The private key is never passed over the wire and is used to construct the same hash on both the client- and the server-side.

STEP 2

The client prepares their request:
* url
* time of request
* action (GET, POST, etc)
* type of request (application/json, etc)
* contents of request
* etc, etc

These components are then turned into a string called the canonical form.

The HTTP protocol is permissive; it treats different requests as if they were the same. For instance it doesn't care about the order in which headers are sent, and allows the same header to contain multiple values as a list or be specified multiple times as a key-value pair.

Intermediate machines between the client and server MAY pack and repack the HTTP request as long as they don't alter its meaning in a narrow sense. This means that the format of the HTTP request is not guaranteed to be maintained.

The canonical form simply ensures that all the valid ways of making the same request are represented by the same string - irrespective of how this is done.

The canonical form handles POST bodies and query parameters and silently discards anchors in URL's.

A hash of this string is made with the private key.

STEP 3

The client makes the request to the server:
* the signature is included in the request in the standard HTTPAuthorization header. (As the Amazon documentation points out this is infelicitous as it is being used for Authentication not Authorization, but hey!).

The Authorization header constructed has the form:
<schema name><space><public key><colon><signature>

An Amazon one looks like:
Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
               --- -------------------- ----------------------------
               sch    public key                 signature

The HTTP request is made.

STEP 4

The request is processed:
* the server receives the request
* the server constructs the canonical form from the attributes of the request:
  - url
  - date header
  - action (GET, POST, etc)
  - content type of request (application/json, etc)
  - some custom headers
  - etc, etc
* the server takes the client's public key from the HTTPAuthorization header and looks up the client's private key
* the server signs the canonical form with the private key
* the server compares:
  - the signature in the request to the signature it has just generated
  - the time encoded in the request with the server time
* the request is accepted or denied

The time comparison is 'fuzzy'. Different server's clocks will be out of sync to a degree, the request may have acquired a time from an intermediate machine along the way, etc, etc. Normally a 'clock skew' time is allowed - in Amazon's case this is 15 minutes.

NOTA BENE: THIS CLOCK SKEW TIME ALLOWS FOR REPLAY ATTACKS WHERE A BAD GUY SIMPLY CAPTURES AND REPLAYS TRAFFIC.

EXTENSION

It is possible to extend this schema to prevent replay attacks. The server issues a nonce token (a random string) which is included in the signature. When the server authorizes the request it stores the token and prevents any request with that token (ie a replay) being authorized again.

The client receives its next nonce token in the response to a successful request.

The Reference Implementation In This Example
--------------------------------------------

The reference implementation used in this example is that described in the Amazon documentation here:
http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?RESTAuthentication.html

The try out the reference implementation:
* create a new mochiweb project as per the mochiweb README
  - make app PROJECT=project_name
* copy hmac_api_lib.erl and hmac_api_client.erl into project_name/src
* copy hmac_api.hrl into project_name/include
* edit project_name_web.erl and add a call to hmac_api_lib:authorize_request/1

authorize/request/1 should be called in the loop of project_name_web.erl as per:

    loop(Req, DocRoot) ->
        Auth = hmac_api_lib:authorize_request(Req),
        io:format("Auth is ~p~n", [Auth]),
        "/" ++ Path = Req:get(path),
        ...

When this is done you are ready to test the api:
* run 'make' in project_name/ to build the Erlang
* start the web server with 'start-dev.sh' in project_name/ (this will also open an Erlang shell to the Erlang VM)

To test the api run this command in the Erlang shell:
* hmac_api_client:fire().

The reference implementation uses 5 constants defined in hmac_api.hrl.
* schema
* headerprefix
* dateheader
* publickey
* privatekey

Building A Custom Implementation
--------------------------------

The simplest custom implementation is to simply take the existing code and change the values of the following constants:
* schema
* headerprefix
* dateheader

If the API is to be used 'as is', please use the values which are commented out in hmac_api.hrl. This will make easier for software developers to work out which version of which client-side libraries they can use.

Client libraries written in other languages than Erlang can reemployment the test suite in hmac_api_lib.erl.

More sophisticated changes will involve changes to the canonicalization functions.

Use of a generic schema should make reuse of client libraries easier across different platforms.

If you develop an ‘as-is’ client-side library in another language please consider submitting its code to this example.

Deploying A Custom Implementation
---------------------------------

When deploying a custom implementation, the server-side code should be released with unit tests so the client-side developer can easily build a robust client.

In addition to that you will need to specify:
* description of how the API works:
  - ie the acceptable methods and urls
  - custom headers and their usage (if appropriate)