Securing Public AWS Application Load Balancer (ALB) with OpenID Connect (OIDC)
Imagine you're the lead developer at a growing tech company with a web application for managing customer accounts. To handle increasing traffic, you decide to move the application to AWS and set up an Application Load Balancer (ALB) to distribute incoming traffic across multiple servers. While focusing on deploying the application swiftly, you end up neglecting the security of the ALB which leaves it publicly accessible without any authentication controls. The traffic ends up being sent over plain HTTP instead of HTTPS leaving sensitive data vulnerable to being intercepted.
As a result, anyone can access the application without needing to log in, including malicious actors. With no encryption, attackers could easily intercept and steal sensitive data like usernames, passwords, and payment information. Additionally, the lack of authentication means unauthorized users can gain access to customer accounts, potentially altering or deleting critical data. To add fuel to the fire, the open ALB could become a target for DDoS attacks, overloading servers and disrupting the service for real customers.
To ensure that such threats are avoided, it is important to properly secure the Application Load Balancer when it is used for accessing business-critical applications. In this blog, you will learn about the AWS Application Load balancer (ALB), and how to effectively secure it with OpenID Connect (OIDC).
What is AWS Application Load Balancer?
The AWS Application Load Balancer (ALB) is a managed AWS service that helps distribute incoming web traffic across multiple services. Unlike other load balancers that operate at the network layer, the ALB works at the application layer Layer 7, which means it can make routing decisions based on the content of the HTTP requests, such as URL paths, HTTP headers, or query parameters. This allows it to support more complex traffic management, such as routing requests to different backend services based on the URL such as /api or /images.
Application Load Balancers are commonly used in cloud applications that need to scale, ensuring high availability by directing traffic only to healthy instances. It’s especially useful in microservices architectures, where different parts of the application may reside on different servers but need to be accessed through a single entry point. ALB can also handle SSL/TLS termination, meaning it can decrypt HTTPS traffic before forwarding it as HTTP to backend servers, simplifying security management.
In real-world scenarios, when deploying applications on Kubernetes, the ALB can be used as the single external entry point for your services. Kubernetes integrates with ALB through an Ingress Controller, which allows you to define routing rules. For example, you could configure the ALB to route traffic based on paths. So requests to /frontend go to the frontend service, and requests to /api go to the Backend API service. This makes it easier to manage the traffic flowing into your cluster and ensure that each microservice receives the correct requests while scaling automatically based on traffic demands.
What is OpenID Connect?
OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0, which is a widely used authorization protocol. OAuth 2.0 allows a user to grant third-party applications access to their resources without sharing their credentials while OIDC adds an additional layer that allows the application to verify the identity of the user. OIDC enables Single Sign-On (SSO) and is often used to authenticate users across different applications, providing a seamless and secure way to handle user logins. It works by using ID tokens which are issued by an Identity Provider like Google, Auth0, or Okta after the user successfully logs in.
For securing your systems, OIDC is valuable because it ensures that only authenticated and authorized users can access your applications. It centralizes authentication, making it easier to manage user identities across multiple services. When you implement OIDC, users don't need to remember separate credentials for each service. Instead, they can log in once, and the identity provider takes care of verifying their credentials and issuing tokens. These tokens, which include user information such as name, roles, and permissions are then passed along to your backend systems, ensuring that only valid users can access protected resources.
In production systems, having OIDC implemented is crucial for maintaining security, especially as your applications scale and become more complex. Without a centralized authentication system like OIDC, managing user access and credentials across multiple services can become a nightmare, leading to potential security vulnerabilities. OIDC allows you to implement strong security practices, such as multi-factor authentication (MFA), to ensure that users are who they say they are. It also enables fine-grained access control, where only users with the appropriate roles or permissions can access sensitive data or perform critical actions, thus reducing the risk of unauthorized access.
How does ALB Authentication work with OIDC?
AWS Application Load Balancer (ALB) and OpenID Connect (OIDC) work together to enhance the security of your web applications by providing a seamless way to authenticate users before they can access your backend services. When you configure an ALB to use OIDC, the ALB acts as a gatekeeper, handling user authentication at the entry point of your application. Instead of routing all incoming traffic directly to your backend servers, the ALB first checks whether the user is authenticated by redirecting them to an Identity Provider such as AWS Cognito, Google, or Okta. Once the user successfully logs in, the IDP issues an ID token, which the ALB uses to verify the user's identity and grant access to the application.
Having OIDC integrated with ALB is important for several reasons. It ensures that your application is protected by a centralized authentication mechanism and users must authenticate through a trusted Identity provider. Only after their identity is verified, they will gain access to the application. This significantly reduces the risk of unauthorized access, as users cannot gain access unless they are authenticated by OIDC for accessing backend services. OIDC enables features like Single Sign-On (SSO), so users only need to log in once across multiple applications, improving the user experience while maintaining secure access.
Configuring OIDC with AWS Application Load Balancer
Let’s take a look at how you can configure ALB with OpenID Connect (OIDC). For this demonstration, we will be using Auth0 to secure the public Application Load Balancer with OIDC.
Step 1: Login To Auth0 By Okta and create an Application
After logging into the Auth0 Dashboard, navigate to the applications tab, and create a new application. You want to create a Regular Web Application. For this application, you will have to generate a client ID and a client secret.
Step 2: Create a Kubernetes Secret
To properly configure the ALB, we need to create a Kubernetes secret with the Client ID and Client Secret that we created in the previous step. The credentials in this Kubernetes secret will be used to authenticate with the Auth0 application.
Using the following YAML, create a Kubernetes secret, and pass in the values of the Client ID and Client Secret that you generated in the previous step.
apiVersion: v1
kind: Secret
metadata:
namespace: testcase
name: my-k8s-secret
data:
clientID: <base64_encoded_clientId>
clientSecret: <base64_encoded_clientSecret>Step 3: Configure the OIDC Integration in ALB.
To configure the OIDC integration in the Application Load Balancer, there are a few things that we need to obtain from Auth0. Please navigate to Applications > Settings > Advanced Settings > Endpoints from the Auth0 Dashboard, and retrieve the following configurations
- Issuer
- AuthorizedEndpoint
- TokenEndpoint
- UserInfoEndpoint
Step 4: Retrieve the following OIDC configuration details:
- Issuer
- AuthorizationEndpoint
- TokenEndpoint
- UserInfoEndpoint
Using these values that you’ve obtained and the secret that you created earlier, you can configure the Application Load Balancer. Within the ALBs configurations, please add the below ALB annotations and use the values that you’ve obtained.
alb.ingress.kubernetes.io/auth-idp-oidc: '{ "Issuer": "https://xxxxxx.us.auth0.com/","AuthorizationEndpoint": "https://xxxxxx.us.auth0.com/authorize","TokenEndpoint": "https://xxxxxx.us.auth0.com/oauth/token","UserInfoEndpoint": "https://xxxxxx.us.auth0.com/userinfo","secretName":"my-k8s-secret"}'
alb.ingress.kubernetes.io/auth-on-unauthenticated-request: authenticate
alb.ingress.kubernetes.io/auth-scope: email openid
alb.ingress.kubernetes.io/auth-session-timeout: "3600"
alb.ingress.kubernetes.io/auth-type: oidc
Within the Auth0 dashboard, navigate to Application’s URIs section and set the Application and CallBack URL for the SSO service
- Login URI: https://<host>/
- Callback URI: https://<host>/oauth2/idpresponse
You can set SSO via social providers such as google from the Auth0 Dashboard. Naviage the Authentication > Social tab in Auth0.
You will see the Google service integrated by default. You can also add more providers from this page. If you wish to use custom domains or providers, you will need to configure the appropriate Client ID and Client Secrets.
Step 5: Manually Configure User Management
After the SSO service is set up, you will have to manually add users. You can add users from the User Management > Users tab in the Auth0 Dashboard.
Click on Create user, and simply enter a username (email address) and password.
If you run into any issues during the configuration process, you can navigate to the Monitoring > Logs page in the Auth0 Dashboard. These logs can help gain insights into error messages and help you to debug the configurations.
Conclusion
In this blog, we've explored how to secure your AWS Application Load Balancer (ALB) with OpenID Connect (OIDC), to streamline user identity verification and enhance the security of your web applications. By configuring ALB to work with OIDC, you can ensure that only authenticated users can access your backend services, providing an essential layer of security for your production systems. The integration of ALB and OIDC allows for seamless user management along with the use of Single Sign-On (SSO), and strong authentication mechanisms such as multi-factor authentication (MFA).
We also walked through the key steps to configure OIDC on ALB, including setting up an Identity Provider (IdP), configuring authentication actions on the ALB, and enabling token validation for secure access control. With these configurations, you can protect your web applications from unauthorized access, ensure secure communication, and enhance the overall user experience.
As your systems grow and become more complex, especially in cloud-native architectures or microservices environments, having a robust authentication mechanism like OIDC becomes increasingly important. By implementing OIDC with ALB, you’re not only improving security but also simplifying user authentication and compliance with industry standards. This approach ensures that your applications are protected, scalable, and ready for production in a secure, reliable environment.
By leveraging AWS ALB’s OIDC integration, you can focus on building great features and delivering value to your users, confident that your security and access management are in safe hands.