Skip to main content

Part 3 - Keycloak - API Gateway APIs with Keycloak JWT authentication


 

In the previous article I showed you how to setup API Gateway in front of your Lambda function.  This article will show you how to setup Keycloak to be used for API Gateway.

Note: once again I am showing you the "ClickOps" method of setting up your environment by doing everything, in this example, though the Keycloak console.  This is not a best practice by any means.  Keycloak has multiple ways to create a script or program to configure it and you should be using tools that allow for repeatability.  But this is meant as a demo and so this version of the document will continue to use this method.

So let's set up a new Keycloak client to handle our API Gateway authorization.  This document will assume that you have a Keycloak instance available on this internet.  It's not too hard to do but look for future articles on the setup for AWS ECS.

To get started, login to your Keycloak instance, change to the correct realm and create a user with a password.  This is a "local" user that isn't tied to a social login like Google.  The user name and password are stored on the Keycloak server.

Next let's create a new client.  Go to "Clients" and then "Create client":


In the next screen, the "Client type" should remain OpenID Connect.  The other choice is SAML which, while Keycloak supports, API Gateway does not.  SAML is similar in concept to Oauth and is a framework for authorization.

Enter a "Client ID" of your choosing.  I'll create "awsapigateway":

Select "Next":


and "Next".  On the third screen there is nothing to enter.  Select "Save" to get to the general configuration screen for the client.

At this point you can use the user you created in the next steps of the process.

Optional - add a client secret to the client.

In some instances it is good to have a Keycloak client have a secret.  This is a shared password that is needed to access the client.  Ultimately it adds an additional layer of security so that only user that know the secret can use the client.

To configure this, go to the client settings tab:


scroll down and turn on "Client authentication":


Save this configuration.  Now, the client configuration includes a "Credentials" tab:

Select the "Credentials" tab and save the "Client Secret" off to your favorite password manager or a file.  We'll use the client secret when we get a token in the last part of this series.

 

Photo by Andy Keyser on Unsplash

Comments

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

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

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