The Overview of how it works
In most cases, you want your API-Gateway routes protected in some ways. AWS offers a couple of ways to do so. In this post, I would like to share the simplest way to control access to your API Gateway for each route. It is using “Lambda Authorizer with Simple Response”.
I am building a React Native application which has a board where anyone can “write” and “read” articles on the board.
Even though it is open to everyone, I want the routes protected. Why? It is because I want people to use the routes “only” through my application. I want everyone to have access to the board, but only through the application.
I think this is very straight forward. But I made an illustration for fun.
As you see, a lambda function plays a role of blocker. The lambda function reads an token passed in client’s http request and determines whether the token is valid or not. If it is valid, it let it go. Otherwise, it blocks access.
The lambda, the blocker
I made a lambda function and named it “apigateway-authorizer-simple-response-for-application”. This will be attached to API-Gateway routes as an authorizer.
I decided to use the “lambda authorizers” out of other authorizers mainly because it enables me to take advantages of customizations. In other words, it is me who establishes logics to determine which tokens are valid which tokens are not. And the logics is the lambda function itself.
The most simple case would be something like this.
The “valid_token_for_applications” array contains valid tokens. If a client passes one of the token in the http request headers, the lambda returns {isAuthorized:true}, which means “OK” to the client’s request.
It is required for the “lambda authorizer with simple response” to return {“isAuthorized”:true or false}. You should set up whatever logic you want in the lambda function and make it return {“isAuthorized”:true or false} at the end.
The API Gateway with authorizer
I have API Gateway, board, which has three routes. In order to set up authorizers with ithe routes, click “Authorization” on the left.
The three routes are open to everyone as long as they send the request from my application.
You should make a new authorizer unless you have one. I have already have one but I will make another one for you.
(1)Authorizer Type: Pick “Lambda” for Authorizer type. I have told you that there are several authorizers, JWT, IAM and Lambda. They all have advantages and disadvantages. I think the Lambda authorizer is the easiest and the most flexible one.
(2)Name: Name it whatever you want. I am very serious in naming things. I use one authorizer for many api routes. And it is the best that the name should be as detail as possible for future uses. I named it “lambda-api-authorizer-simple-response-for-application”.
(3)Lambda function: Pick the lambda function we have made (apigateway-authorizer-simple-response-for-appliation). Basically, the lambda authorizer is a lambda function that returns either {“isAuthorized”:true} or {“isAuthorized”:false}
(4)Response Mode: Pick “Simple”. Again, the lambda authorizer only returns {“isAuthorized”:true} or {“isAuthorized”:false}
(5)Identity Source: Do not change it unless you want to map tokens in your own way. “$request.header.Authorization” means you can pass a token in {headers: {Authorization: token}.
You are all set. Click “Create and attach” If you successfully attach the authorizer to the routes, you will see green badges on the right side of the routes.
More
In this example, reading and writing the board was open to anyone so that the token only needs to tell which application is sending requests.
However, in case I need to add functionalites such as “deleting” or “updating” articles on the board, I will need tokens that can tell which “user” is sending requests because Mike should not be able to delete what John has uploaded. It requires more complex logics in the authorizer. I will post that later.
Thank you for reading my blog.
