DEV Community: Antonio Perez

Create a HMAC Authorization Header in NodeJS

Antonio Perez — Mon, 29 Jul 2019 03:09:37 +0000

There are a ton of HTTP Authorization methods to use when trying to authenticate against an API. One such is the Hash Message Authentication Code (HMAC) authentication scheme. This method provides a way for the server to cryptographically verify the request by hashing the request itself, and then creating the MAC out of the HTTP method, request URI, hostname, and the request body hash.

HMAC NODEJS EXAMPLE GIST LINK

The server you are attempting to authenticate against will provide you with three key pieces of data.

The MAC key id
The MAC secret key with the expected hash algorithm. If the key is base 64 encoded. You will have to decode it when generating the HMAC.
Issue time of your credentials in EPOCH.

Generally, the server will use the MAC key id to look up your issued credentials on their end. The MAC secret key will be used to generate the HMAC just before sending the request to the server. The server will use this same secret key to compute the mac. If there is a mis-match, the request will be rejected.

A resulting HMAC header may look like this..

Authorization: "MAC id='SERVER-PROVIDED-ID', nonce='6573561:WINTERBOOTS', bodyhash='pWZ7PIoST1E8QP70NAbNfSVfl/U0BFWk596zZuBuh84=', mac='qh4lj5GpmJd5yvxX8BUXU5j6orDUsCYBMNhjIFOA21E='"

Lets break down the MAC header into the main components

id – The server provided ID
nonce – The number of seconds since the provided issued time concatentated with a random string, separated by a ‘:’ character.
bodyhash – The result of =BASE64(HASH(requestText))
mac – =BASE64(HMAC(macString, secretKey))

The MAC before it is created needs to be formatted and preserved as a normal text string so the server and client can calculate the request MAC over the exact same value. Each piece of data is separated by a new line character (\n). Let’s review each of the 7 pieces of data. This order must be maintained in the string.

MAC normalize string

The nonce value generated for the request.
The HTTP request method in upper case. For example: “HEAD”, “GET”, “POST”, etc.
The HTTP request route ex) ‘/users’
The hostname included in the HTTP request
The port ex) 80 for HTTP or 443 for HTTPS
The request payload body hash, otherwise, an empty string.
The value of the “ext” “Authorization” request header field, otherwise, an empty string.

${nonce}\n ${method}\n ${route}\n ${hostname}\n ${PORT}\n ${bodyHash}\n ${ext}\n

Great. Now that we have the string, we can now calculate the MAC portion of the request. The result is the base 64 encoded result of the HMAC(string, secretKey). Remember, if the secret key is base64 encoded, you will have to decode it. Below is a Node js gist that takes advantage of the crypto libray to generate the hash, HMAC, and auth header for your API integration.

The code sample creates an HMAC for a /users POST endpoint being hosted at example.com. The result is a header object that can be used in Axios or most HTTP libraries. The request is converted to stringified json.

Happy coding!

HMAC NODEJS EXAMPLE GIST LINK

An AWS Code Build spec for your typescript node project

Antonio Perez — Sat, 15 Jun 2019 17:00:49 +0000

AWS Code Build is a great addition to your AWS infrastructure. Today, we are going to focus on one aspect of the software deployment process. Building! Before we dive in, let me provide some context about the architecture and my plan for the CI/CD process. The project behind this post is a node.js express project written in typescript. The API is served on Elastic Bean Stalk. We want to auto deploy our code versions to elastic beanstalk by using AWS Codebuild and then later Code Pipeline to push the resulting build to the Elastic Bean Stalk instance.

Deployments suck. You build this great product on your local machine and now you have to deploy it to the masses. You spent so much time focusing on the product, that you forgot to scope out the deployment process. It’s DevOps! How hard can it be?! … err.. guilty. There are so many ways to do deployment, as is common in this field. You can easily spend a whole day researching different deployment tools for your environment. You try to understand why certain products exists, weigh the pros and cons of each based on opinionated words of others. Perhaps integrations between different platforms are possible. Travis for AWS? How are those set up? Death by a thousand choices and words. Now with the setup above, we can focus on our code, and let automation tools worry about the builds. I also wanted to keep it all on AWS.

Let’s worry about Git. Branch management is important, but that’s a different topic for another day. In my project, I have two special branches, a ‘staging’ and a ‘production’ one. I have two AWS Code Build configurations watching these two branches for any changes. If a change is detected, for example, I merged my development branch into staging or staging into production, a code build will fire and the pipeline is executed. A minute later, our project has a new release! Magic!

For AWS Code Build, you need a buildspec.yml in your git repo to tell the server how to install and build your project. In this case, my package json file has an npm command called build-ts that runs tsc. You can also include your tests command here, but I’ll come back to that at a later post.

The artifacts section is also important. Elastic Bean stalk expects us to zip the contents of the result, not the resulting build folder. So I am grabbing three things here. The package.json file, the read me, and the contents of the dist folder.

//buildspec.yml
version: 0.2
phases:
    install:
        commands:
            - 'npm install'
    build:
        commands:
            - 'npm run build-ts'
artifacts:
    type: zip
    files:
        - package.json
        - package-lock.json
        - 'dist/**/*'
        - LICENSE
        - README.md
        - .npmrc

Head on over to AWS Pipeline to setup a pipeline. When you set up a pipeline, you can set the source, and later a build project. It’s easier than going to each step, setting it up individually, and later connecting them. I plan on showing each step in detail in my next post, but hopefully you’re at a point where you either need the build spec, or just a general overview of this type of AWS infrastructure. Happy coding!