Skip to main content

Part 2 - the Gateway - API Gateway APIs with Keycloak JWT authentication


In part 1 of this series I showed you how to setup an AWS Lambda with the AWS console.  Now, let's protect that Lambda with API Gateway and a JWT Authorizer, specifically with Keycloak.

The JWT Authorizer in API Gateway expects a standard JWT to be passed on every call to the API.  This leverages the standard Authorization header to pass the token. A curl call to the API might look like:

 

curl https://2ozg2rh13f.execute-api.us-west-2.amazonaws.com/default/api-gw-dad-joke
   -H "Accept: application/json"
   -H "Authorization: Bearer {token}"
  

 where the token is a JWT that looks something like:

eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJq ...
 

In the next article I'll show you where to get this token.  But first, let's put an API in front of the Lambda.

  

Note: once again I am showing you the "ClickOps" method of setting up your environment by doing everything though the AWS console.  This is not a best practice by any means.  Best practice is to use a toolkit such as AWS CDK or others to have an IaC (Infrastructure-as-Code) environment.  An IaC environment allows you to reproduce your overall infrastructure easily and allows much simpler auditing.  But this is a demo - it's not meant to be the be-all and end-all for AWS best practices.

Once you have the Lambda setup, the easiest way to begin to create an API Gateway is to leverage the UI to create the integration.  So, start by going to the AWS Console for Lambda and select your Lambda:

 and then "Add trigger".  In the next screen, select "API Gateway" in the select list:


Select "Create a new API" and then "HTTP API".  Note that at first we're going to select "Open" under "Security".  We'll secure it with JWT in just a few steps:

 

and select "Add".  The console with "think" for a second or two and bring you back to the Lambda screen:


Your Lambda is now available on the internet to be called!  Let's test it out. First, get the URL that was assigned to this integration by API Gateway.  Click on the "API Gateway" box in the image above to show the integration parameters:



Of course, your URL will be different than mine but the concept is the same.

Using your browser or Postman, go to the URL that you've been assigned.  In Postman, the response will be something like:

This is exactly what the service does - it acts as a proxy for the icanhazdadjoke.com API.  In this integration JSON is returned from the icanhazdadjoke.com API and that JSON is returned by the Lambda code behind the API Gateway.

But this API is now available to the world.  While it seems highly unlikely that someone would want to abuse this particular API - your service is likely to be a bit more interesting - it still should be protected from the world being able to access it.  See part 3 for the JWT part of the article.

 

Photo by Silas Köhler on Unsplash

Comments

Post a Comment

Popular posts from this blog

Generating JWT's using the Auth0 library

I've created a small example set of code to generate and learn about JWTs .  This code allows you to create and sign your own JWT.  You can create your own public/private keys to sign and verify the tokens. In and of itself this code would not likely be used for a production environment but knowing how a JWT works and the part of it are an important part of understanding Oauth2 in general.  I've got some future code to show you how to use a JWT in more of a production environment but this is useful to learn from.   Photo by Maick Maciel on Unsplash
Post a Comment
Read more

Starting SSO with Keycloak

  I've been using  Keycloak  for years now and have been experimenting with the newer versions that are based on top of  Quarkus .  One of the struggles I've had is spinning up a test server for development.  The new Quarkus model though is pretty simple.  A small  Docker Compose  script let's you spin up an environment in almost no time. My script looks like: version: '3.8' services: postgres: image: postgres:latest environment: POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} restart: unless-stopped healthcheck: test: [ "CMD-SHELL", "pg_isready -U postgres" ] networks: - pg_network volumes: - ./pgdata:/var/lib/postgresql/data - ./create_db.sql:/docker-entrypoint-initdb.d/create_db.sql keycloak: image: quay.io/keycloak/keycloak:latest depends_on: postgres: condition: service_healthy environment: KC_DB: ${KC_DB} KC_DB_URL: ${KC_DB_URL} KC_DB_USERNAM
Post a Comment
Read more

Part 1 - the Lambda - API Gateway APIs with Keycloak JWT authentication

  AWS AP I Gateway is an AWS service to "front" a variety of AWS services by providing an HTTP front end.  One common use is to access logic coded into an AWS Lambda to allow services and web browsers to access the Lambda and it's services.  A Lambda is one of the main tools for serverless development in the AWS ecosystem. If your API Gateway service is public (meaning it's not enclosed within a VPC) then anyone in the world meaning can use (and abuse) your API.  Therefore, it is imperative to have some sort of validation check on who is calling the API and to make sure the caller is authorized to interact with the API. So this set of posts will show you how to use one of the types of API Gateway authorization, JWT authorizers .  JWT is a standard for tokens that are passed (usually over HTTP) from a consumer to a service.  It is most commonly used in Oauth2 environments. API Gateway has two synchronous ways of interacting with it, along with a Websocket integra
Post a Comment
Read more