Skip to content

Using Amazon (AWS) Cognito, Lambda, IAM, and API Gateway to Build Secure Microservice APIs

In this article I will attempt to provide a brief overview of what is necessary in order to create an architectural ecosystem that supports role based authorization and authentication of a Restful API.  To achieve this, I am using Amazon Web Services (AWS), and more specifically the following services it provides:

  • API Gateway
  • Lambda
  • IAM
  • Cognito Identity

With these it is possible to simplify the process of securing your web application and APIs.  So let’s get started

The first product I will introduce is Amazon Cognito, and more specifically the Identity Pool aspect of it. This allows you to create an Identity Pool, which is a store of user identity data specific to your account.  Each user will be assigned an IdentityId  which is the unique identifier for that user within the cognito user store.  In database terms think of it as the primary key for the user.  Now, for each user there will be two types, unauthenticated and authenticated ones. Cognito will assign temporary, limited-privilege credentials for each authorized user.  Here are the typical use cases for the 2 types of users:

  • Unauthenticated
    • Typically used for situations where you want your app or api to be secure, but not necessarily require your users to register or login.  An ecommerce site where users should be able to browse a product catalogue and add items to their shopping cart prior to logging in would be an example of this. This part of your api should be secured so it can only be called by these areas of your application and reject calls from anything else included external sources.
  • Authenticated
    • Typically used when you want to implement role based authentication (I am who I say I am) and authorization (I am allowed to access the resource I cam requesting).  So using the ecommerce example, it would be necessary to allow users to create an account, login, and purchase items.  Also, it would be necessary to have a secure way to manage the product catalog.  Thus, we have the concept of a shopper and a seller.  For authenticated users Cognito Identity currently supports the following Identity Providers:
      • Amazon
      • Facebook
      • Google
      • Developer authenticated identities (You create your own user datastore and validate your users with your own logic)

Cognito Identity will create or allow you to create 2 IAM roles. There is a role for unauthenticated users and one for authenticated users.  These 2 roles are what will be impersonated and allow the user to access certain AWS resources based on the trust relationships defined, and access policies, for each role. For Authenticated users, as mentioned prior, you can create your own identity provider.  This involves using a datastore of some sort to store your users, validate their password, hash it, store it, and also determine what type of user that each is (shopper, seller, etc…).  Once implementing this, you would integrate with the Cognito Developer API to then generate the needed credentials once your users have been authenticated.  It is required that you provide a unique “token” just like the public providers such as Facebook and Google do.  A prime candidate for this would be to use the unique user id of the user as it’s stored in your own data store.

To generate the needed credentials for Amazon Cognito, it is a multi sept process that is done using their provided developer APIs.  I will cover in a later installment of this post and provide examples, but for now, here is a link that discusses this.

The next piece of this is AWS Lambda, which is what will be used to create a full featured restful API (once hooked up to API Gateway).  Lambda will provide a stateless and isolated container to run your code for each endpoint(s).  I have already written an article that goes into some of the details on Lambda.  For developer authenticated identities, Lambda will also be used to provide the login and registration API itself.  As we create our API, we can then specify for each lambda function which roles can execute it.  As part of the login and registration process using the Cognito Developer API, we can generate a set of credentials for both user types.  These credentials will be used from the consumer of the API, and will be passed along in each request, using sig4.

Finally we get into AWS ApiGateway, the service that will present our lambda functions to the world, if they will be exposed publicly that is.  With api gateway we can easily create a fully functional Restful API around our lambda functions. Each endpoint can be secured by IAM which in turn requires the credentials that are passed back to the client.  Another awesome feature of API Gateway is the ability to generate a fully functioning client library for your api, which also takes care of properly signing and passing along your credentials along with each API call.  Currently the generated client libraries can be generated in for Android, IOS, and also in JavaScript.

 

Stay tuned for part 2 of this article, where I will give code and implementation examples of the concepts discussed.

Written for ServerlessArchitecture.com
Written by Jeff Mangan

Leave a Reply