DEV Community: Promise Ogbonna

API Authorization with AWS at Emergency Response Africa

Promise Ogbonna — Mon, 04 Oct 2021 15:21:18 +0000

Introduction

Emergency Response Africa is a healthcare technology company that is changing how medical emergencies are managed in Africa.
As you can imagine, this means we manage a lot of web and mobile applications, used internally and externally.

The importance of securing access to resources from these client applications can't be overstated. The wrong user having access to the wrong resources can cause a lot of problem.

In this post, I'll discuss in detail how we handle Authorization to our internal APIs using Amazon Web Services (AWS) and how we determine the extent of the permissions to assign to the client making the request.

What is Authorization

Authorization is the process of verifying the resources a client has access to. While often used interchangeably with authentication, authorization represents a fundamentally different function. To learn more, read this post on Authentication and Authorization by Auth0.

Our Workflow

Our workflow is pretty simple, and our API is deployed using the Serverless Application Model

In this architecture, we make use of TOKEN Lambda authorizer. This means it expects the caller's identity in a bearer token, such as a JSON Web Token (JWT) or an OAuth token.

The client app calls a method on an Amazon API Gateway API method, passing a bearer token in the header.
API Gateway checks whether a Lambda authorizer is configured for the method. If it is, API Gateway calls the Lambda function.
The Lambda function authenticates the client app by means generating an IAM policy based on the preconfigured settings in our API.
If the call succeeds, the Lambda function grants access by returning an output object containing at least an IAM policy and a principal identifier.
API Gateway evaluates the policy.
If access is denied, API Gateway returns a suitable HTTP status code, such as 403 ACCESS_DENIED.
If access is allowed, API Gateway executes the method.

Implementation

The most technical aspect of this post.
TLDR, You can jump straight to the code on GitHub.

First thing, define the resources in our SAM template.

This includes:

The API
Authorizer
Environment variables template.yml.

Globals:
  Function:
    Runtime: nodejs12.x
    Timeout: 540
    MemorySize: 256
    Environment:
      Variables:
        # Environment variables for our application
        STAGE: test
        USER_POOL: eu-west-1_xxxxxxxxx
        REGION: eu-west-1

Resources:
  ApplicationAPI:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref Stage
      Auth:
        DefaultAuthorizer: APIAuthorizer
        Authorizers:
          APIAuthorizer:
            FunctionPayloadType: REQUEST
            # Get the Amazon Resource Name (Arn) of our Authorizer function
            FunctionArn: !GetAtt Authorizer.Arn
            Identity:
              Headers:
              # Define the headers the API would look for. We make use of Bearer tokens so it's stored in Authorization header.
                - Authorization
               # Caching policy; here we define in seconds how long API Gateway should cache the policy for.
              ReauthorizeEvery: 300

  Authorizer:
    Type: AWS::Serverless::Function
    Properties:
      # Reference the relative path to our authorizer handler
      Handler: src/functions/middlewares/authorizer.handler
      Description: Custom authorizer for controlling access to API

We implement our authorization function authorizer.js

const { getUserClaim, AuthError, getPublicKeys, webTokenVerify } = require("./utils");


/**
 * Authorizer handler
 */
exports.handler = async (event, context, callback) => {
  const principalId = "client";

  try {
    const headers = event.headers;

    const response = await getUserClaim(headers);
    return callback(null, generatePolicy(principalId, "Allow", "*", response));
  } catch (error) {
    console.log("error", error);
    const denyErrors = ["auth/invalid_token", "auth/expired_token"];

    if (denyErrors.includes(error.code)) {
      // 401 Unauthorized
      return callback("Unauthorized");
    }

    // 403 Forbidden
    return callback(null, generatePolicy(principalId, "Deny"));
  }
};

/**
 * Generate IAM policy to access API
 */
const generatePolicy = function (principalId, effect, resource = "*", context = {}) {
  const policy = {
    principalId,
    policyDocument: {
      Version: "2012-10-17",
      Statement: [
        {
          Action: "execute-api:Invoke",
          Effect: effect,
          Resource: resource,
        },
      ],
    },
    context, // Optional output with custom properties of the String, Number or Boolean type.
  };

  return policy;
};

/**
 * Grant API access to request
 * @param {object} h Request headers
 */
exports.getUserClaim = async (h) => {
  try {
    const authorization = h["Authorization"] || h["authorization"];

    const token = authorization.split(" ")[1];
    const tokenSections = (token || "").split(".");
    if (tokenSections.length < 2) {
      throw AuthError("invalid_token", "Requested token is incomplete");
    }

    const headerJSON = Buffer.from(tokenSections[0], "base64").toString("utf8");
    const header = JSON.parse(headerJSON);
    const keys = await getPublicKeys();
    const key = keys[header.kid];
    if (key === undefined) {
      throw AuthError("invalid_token", "Claim made for unknown kid");
    }

    // claims is verified.
    const claims = await webTokenVerify(token, key.pem);
    return { claims: JSON.stringify(claims) };
  } catch (error) {
    const message = `${error.name} - ${error.message}`;
    if (error.name === "TokenExpiredError")
      throw AuthError("expired_token", message);

    if (error.name === "JsonWebTokenError")
      throw AuthError("invalid_token", message);

    throw error;
  }
};

We implement our utils file utils.js

const { promisify } = require("util");
const fetch = require("node-fetch");
const jwkToPem = require("jwk-to-pem");
const jsonwebtoken = require("jsonwebtoken");

/**
 * Get public keys from Amazon Cognito
 */
exports.getPublicKeys = async () => {
  const issuer = `https://cognito-idp.${process.env.REGION}.amazonaws.com/${process.env.USER_POOL}`;
  const url = `${issuer}/.well-known/jwks.json`;
  const response = await fetch(url, { method: "get" });
  const publicKeys = await response.json();

  return publicKeys.keys.reduce((total, currentValue) => {
    const pem = jwkToPem(currentValue);
    total[currentValue.kid] = { instance: currentValue, pem };
    return total;
  }, {});
};

/**
 * Using JSON Web Token we verify our token
 */
exports.webTokenVerify = promisify(jsonwebtoken.verify.bind(jsonwebtoken));

/**
 * Generate Auth Error
 */
exports.AuthError = (code, message) => {
  const error = new Error(message);
  error.name = "AuthError";
  error.code = `auth/${code}`;
  return error;
};

We define helper functions to help us parse our event request.

Our claims is stored in event.requestContext.authorizer.
From our authorization function above we are only able to pass strings from our API Gateway authorizer, so it's stringified in the claims objects

helpers.js

 * Parse claims from event request context
 * @param {import("aws-lambda").APIGatewayProxyEvent} event
 */
exports.parseClaims = (event) => {
  return JSON.parse(event.requestContext.authorizer.claims);
};

Conclusion

This rounds up our implementation.
This post serves as a reference to how we implemented authorization in our API, any further updates to our workflow would be made on this post.

For more clarification, you can reach out to me on Email or Twitter

Resources

Use API Gateway Lambda authorizers

How We Collect Payments at Medherd

Promise Ogbonna — Mon, 07 Sep 2020 20:28:29 +0000

At Medherd, we create a platform for medical practitioners and businesses to stay ahead of what's going on in the digital health space. Keeping them updated and providing a collaborative environment to discover and review products and most importantly share ideas.

In doing that, we aim to get paid. This post is a guide on how we handle payments at Medherd using Stripe in a robust and secure manner, and we hope this can help you navigate the large Stripe documentation.

Medherd is built Serverlessly on Google Cloud Platform, with Cloud Functions at the heart of our architecture. All the endpoints used in our payment setup are created with Cloud Functions.

A Plan

First, we had to decide on how our "Plans" would be structured.

A plan is seen as a "mixture" of products and prices, which are created either through the stripe dashboard or using the Products API and Prices API respectively.

A product can have one price. This is the most common implementation you'll find in SAAS payment structures. This is also what we use at Medherd.

A product can also have multiple prices. A use case for this would be a product with an annual, monthly and weekly variation.

Types of Plans

Stripe allows you to create 2 types of plans.

Recurring Plans (Subscription) - These are subscription based plans, used to collect payment on a weekly, monthly or annual basis depending on your billing structure
One-Time Plans - These are plans that are to be paid for at once. Similar to products sold on an e-commerce platform.

Setup a User for Billing

This is the first and most important step. When a user creates an account on our platform, we create a customer account for the user on Stripe, making use of the Customers API.

Ideally, for every user on our platform, there is a customer account on Stripe.

Recurring (subscription) Payments

Using the SetupIntents API and the Subscriptions API, we handle subscriptions in the smoothest way possible.

Using the SetupIntents API, we create an "intent" to "setup" a user for a recurring billing. After the intent has been setup, we can collect payment details using the Stripe client-side SDK, and then create the subscriptions on our platform.

One-Time Payments

Using the PaymentIntents API (similar to the SetupIntents API), we create an "intent" to receive "payments", and then complete this process using the confirmCardPayment method directly on the client device, making use of the client-side SDK.

Stripe Webhooks

Stripe Webhooks allow us to respond to events we care about. This is done on the Stripe dashboard.

We create an endpoint which we add to Stripe, and select the events we would like to be notified of.

Using this approach, we stay ahead of everything going on with payments and are able to respond to activities that have occurred on Stripe, such as payment_intents.payment_failed or setup_intents.canceled.

This enables us to be act accordingly to activities that have occurred in our platform, such as recording a transaction in our database, notifing the user through email or in-app or in terrible situations retry the billing process.

More Uses

We also have more uses which are not covered thoroughly in this post, but are pretty simple to implement.

This includes

Get Plans - Get plans to display to a user
Get User Subscriptions - Display existing subscriptions to the user.
Cancel User Subscription - Cancel an existing user subscription
Set User Card - Set a default card, which the user uses for future payments

Conclusion

This guide also doubles as a personal documentation to know how we have implemented payments. Expect this to be updated as time goes on.

You can also checkout the following Stripe tutorials to see how Stripe suggests to make use of the API.

Should I Read a Programming book from the beginning to the end

Promise Ogbonna — Mon, 24 Aug 2020 11:47:44 +0000

As a programmer, do I still need to read a book from the beginning of the book to the end of the book before I get started in that technology ?

Do you use a UI kit for your front-end and how do you decide on which to use ?

Promise Ogbonna — Mon, 25 Mar 2019 15:31:03 +0000