Deep Dive on Advanced features on AWS Application Load Balancer and Network Load Balancer

I will try to share tips and tricks about the latest AWS Application Load Balancers (ALBs) and Network Load Balancer features. I will try to explain the best ways to deploy, configure, and leverage these features.

How to use Lambda functions as targets for Application Load Balancer to serve HTTP(S) requests.

Using built-in authentication in Application Load Balancers to securely authenticate users as they access applications.

Explain the expanded routing criteria in content-based routing rules to set up complex rules to route client requests to applications with Advanced Request Routing, Fixed Response, Redirect, Server Name indicator.

Let’s have a look at elastic load balancing family currently there are three types of load balancers.

AWS ELB Family

Application load balancer (ALB) is best suited for load balancing of HTTP and HTTPS traffic. Application load balancer (ALB) operates at OSI Layer 7 at the request level and provides advanced request routing features such as path and host based routing web sockets HTTP 2 and other visibility features targeted and application architectures including micro services.

Network load balancer (NLB) operates at OSI Layer 4 and best suited for load balancing of TCP traffic (transmission control protocol) and TLS (transport layer security) traffic where extreme performance is required. NLB operates at the connection level and are capable of handling millions of requests per second while maintaining ultra low latencies. Network load balancer also supports static IP functionality where you get a single IP per availability zone.

Classic load balancer that provides load balancing across multiple ec2 instances and operates at both layer 7 the request level and layer 4 the connection level. However there are no investments on classic load balancer and eventually it will be phased out. Therefore use the classic load balancer only for applications that were built using the older ec2 classic network and if you are not using the VPC.

Let’s look at some of the benefits of what the elastic load balancing family offers:

Highly available

Elastic Load Balancing automatically distributes incoming traffic across multiple targets — Amazon EC2 instances, containers, IP addresses, and Lambda functions — in multiple Availability Zones and ensures only healthy targets receive traffic. Elastic Load Balancing can also load balance across a Region, routing traffic to healthy targets in different Availability Zones. The Amazon Elastic Load Balancing Service Level Agreement commitment is 99.99% availability for a load balancer.

Secure

Elastic Load Balancing works with Amazon Virtual Private Cloud (VPC) to provide robust security features, including integrated certificate management, user-authentication, and SSL/TLS decryption. Together, they give you the flexibility to centrally manage TLS settings and offload CPU intensive workloads from your applications. ELB can establish a private connection between virtual private cloud (VPC) and the Elastic Load Balancing API by creating an interface VPC endpoint. You can use this connection to call the Elastic Load Balancing API from your VPC without sending traffic over the Internet. Interface VPC endpoints are powered by AWS PrivateLink, a feature that enables private communication between AWS services using private IP addresses.

Elastic

Elastic Load Balancing is capable of handling rapid changes in network traffic patterns. Additionally, deep integration with Auto Scaling ensures sufficient application capacity to meet varying levels of application load without requiring manual intervention.

Flexible

Elastic Load Balancing also allows you to use IP addresses to route requests to application targets. This offers you flexibility in how you virtualize your application targets, allowing you to host more applications on the same instance. This also enables these applications to have individual security groups and use the same network port to further simplify inter-application communication in microservice-based architecture.

Robust monitoring & auditing

Elastic Load Balancing allows you to monitor your applications and their performance in real time with Amazon CloudWatch metrics, logging, and request tracing. This improves visibility into the behavior of your applications, uncovering issues and identifying performance bottlenecks in your application stack at the granularity of an individual request.

Hybrid load balancing

Elastic Load Balancing offers ability to load balance across AWS and on-premises resources using the same load balancer. This makes it easy for you to migrate, burst, or failover on-premises applications to the cloud.

Elastic load balancer family are integrated with 14+ other AWS services including auto scaling for scaling requirements for your back-end targets. Route 53 for DNS. Amazon Cloud watch for metrics. ECS and EKS for containers. Code deploy for deployment. AWS config also ACM which is the certificate manager and so on.

Overview of recently launched features on ALB and NLB

Before we get into the deep dive for the specific areas. I want to go over some of the recent features that were launched on the application and network load balancer. ELB has Console support for filtering by tags, Resource and Tag based permissions for ALB and NLB which enables to implement fine-grained access controls on load balancers using IAM policies. Slow Start for ALB. By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check. Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests. After you enable slow start for a target group, targets enter slow start mode when they are registered with the target group and exit slow start mode when the configured slow start duration period elapses. The load balancer linearly increases the number of requests that it can send to a target in slow start mode. After a target exits slow start mode, the load balancer can send it a full share of requests. User authentication support on ALB allows you to configure an application load balancer to securely authenticate users as they access applications this enables you to offload the work of authenticating users to load balancers so that applications can focus on their business logic. AWS Lambda as a target on ALB. Lambda functions are supported in addition to ec2 instances and IP based targets to the load balancer. Advanced Request Routing beyond the path and the host based routing that already supported. I will be going deeper into each of these three areas user authentication, AWS lambda as a target, and the advanced request routing. Some of the other recent features that launched on the application load balancer and network load balancer are more TLS policies to load balancers. (ELB Security Policy FS 2018 06 and ELB Security Policy TLS 1 2 Ext 2018 06) these recent policies implement ciphers that ensure forward secrecy on the application load balancer. Ability to do redirects natively from the load balancer where you can redirect from 80 to 443 or HTTP to HTTPS or from one URL to another. Fix response is another interesting feature added to the ALBS that allows you to send a fixed response from the load balancer itself based on certain conditions. Network load balancer added support for cross-zone load balancing NLB, Inter and intra region peering and VPN support for NLB, support for TLS termination on NLB that allows you to terminate TLS while still preserving the source of the clients. Network Load Balancers support UDP. We can now use NLB to deploy connectionless services for online gaming, IoT, streaming, media transfer, and native UDP applications. If you are hosting DNS, SIP, SNMP, Syslog, RADIUS, and other UDP services in your own data center, you can now move the services to AWS. You can also deploy services to handle Authentication, Authorization, and Accounting, often known as AAA.

You no longer need to maintain a fleet of proxy servers to ingest UDP traffic, and you can now use the same load balancer for both TCP and UDP traffic. You can simplify your architecture, reduce your costs, and increase your scalability.

Agenda

ALB Features

I will be going deeper into each of these three areas user authentication, AWS lambda as a target, and the advanced request routing. First one is advanced request routing, redirects, fixed response then lambda functions targets and finally authentication.

Advanced Request Routing

New request routing criteria into the content based routing of alb. These new criterias are:

• Standard/custom HTTP headers
• Standard/custom HTTP methods
• Query parameters and query string
• Source IP addresses

Prior to this ALB support for host header and path based routing. ALB has ability to route based on pretty much any field in an HTTP request except the body. Let’s look at a typical request.

Typical Request

What you see above is a get request. Starts with GET, which is a method so you can route based on method. Then you have path /hello.htm, you can route based on this. Then you have query string for query parameters you can route based on them. Next thing is a host header and host header based routing that existed from the launch. Now what is added is the ability to route based on any custom or standard headers. So pretty much everything covered in an HTTP request.

Let’s look at the use cases where we can benefit from this new routing criteria. With user agent based routing, we can separate bot traffic from human users and provide a different kind of experience to each of these categories. Similarly, we can provide a variety of user experiences based on the category of devices using the user agent header or the geographic location of users using the source IP addresses. Another use case is for query string based routing is a/b testing. Similarly, on the deployment side we can use header based routing for Bluegreen deployments or Canary deployments. On the micro-services, the method based routing comes very handy when you want to have micro-services handlers based on methods. For example, you can have get and head methods routed to a read service while you route post and put methods to a write service. Finally, you could also employ excess restrictions based on IP addresses or CDN networks using source based routing an IP address.

Now lets have a look and understand how the actions and conditions work in AWS ALB rules. A rule can have one or more conditions. And one or more actions. Basically we have routing criteria’s which are the conditions, condition types and then actions.

Conditions and Actions

When it comes to the actions:

ALB Actions

Forward to routes the request to a target group (a set of EC2 instances, a Lambda function, or a list of IP addresses). Redirect to generates a 301 (permanent) or 302 (found) response, and can also be used to switch between HTTP and HTTPS. Return fixed response generates a static response with any desired response code. Authenticate uses Amazon Cognito or an OIDC provider to authenticate the request (applicable to HTTPS listeners only).

You can use this feature with your existing Application Load Balancers by simply editing your existing rules. Here are a couple of other things that you should know about this cool and powerful new feature:

Metrics — You can look at the Rule Evaluations and HTTP fixed response count CloudWatch metrics to learn more about activity related to your rules (learn more):

CloudWatch Metrics

Programmatic Access — You can also create, modify, examine, and delete rules using the ALB API and CLI(CloudFormation support ready).

Rule Matching — The rules are powered by string matching, so test well and double-check that your rules are functioning as intended. The matched_rule_priority and actions_executed fields in the ALB access logs can be helpful when debugging and testing (learn more).

Limits — Each ALB can have up to 100 rules, not including the defaults. Each rule can reference up to 5 values and can use up to 5 wildcards. The number of conditions is limited only by the number of unique values that are referenced.

ALB allows you up to five match evaluations per rule right now. You can consume these evaluations in one condition or a cross up to five conditions. It does not matter the limit applies to the rule level. Similarly, you can also use, up to five wild cards per rule. The overall limit of 100 rules per load balancer. Flexibility of five values in one rule gives you to combine multiple individual rules to fewer rules. Let’s say for example path rules where /login and /signin were for to the same target group. Now you can do them with one rule rather than two.

Now for the demo of advanced request based routing. You can find all the demos and explanations at https://exampleloadbalancer.com/advanced_request_routing_demo.html.

Query Parameters based Routing

Query Parameters

In example above based on query parameters theme bright and / path request routed target group 1. (https://exampleloadbalancer.com/arr_parameter?theme=bright)

Also based on query parameters theme dark and / path request routed target group 2. (https://exampleloadbalancer.com/arr_parameter?theme=dark)

1. When you click the button, a HTTP request is sent to the “exampleloadbalancer” demo Application Load Balancer with a query parameter in the URI
2. There are two routing rules configured on the Application Load Balancer which route request to different target groups based on the query parameters in the request
3. When you use the query parameter “theme=bright”, the Application Load Balancer returns the page of bright theme. Similarly, you will see the same web page of dark theme when you use ”theme=dark” in the request query parameter.
4. Pattern match for query string is case-insensitive

For each evaluation in a condition, a successful match occurs if the query parameters in the query string matches the key-value pair that is provided as an input including any wildcards. A wildcard “*” (matches 0 or more characters) and a wildcard “?” (matches exactly one character) can be used though it is advised that you avoid use of “*” and “?” in the query string. If present, “*” and “?” is interpreted literally as a character and to differentiate these from wildcards in the match string, you need to precede these characters with an escape character.

Query parameters based routing

You can use multiple query parameters to let the Application Load Balancer route requests to different target groups. In demo, one more query parameter — “gif” added, through which you can specify the GIF that you want to see on the web page. Please check and try https://exampleloadbalancer.com/advanced_request_routing_queryparam_overview.html

HTTP method based Routing

HTTP MethodHTTP Routing

1. When you click the “GET” button, a HTTP GET request is sent to the “exampleloadbalancer” demo Application Load Balancer.

2. There are two routing rules configured on the Application Load Balancer.

Rule1: The Application Load Balancer returns a fixed response static page for any GET requests for path /arr_method.

Rule2: The Application Load Balancer routes any POST requests for path /arr_method to a Lambda target group which parses the city data in the POST request and returns the weather information of the given city

3. The HTTP method name that you configured has to be an exact match with the HTTP method in the request.

4. Wildcards are not supported in the match string and method name is case-sensitive.

5. Custom methods are supported. For example you can use method like RENEW, ALLOC, FIND etc. Only upper case alphabets (A-Z), hyphen (-) and underscore ( _ ) are allowed characters in the method name. Examples VERSION-CONTROL, CUSTOM_METHOD, ALLOW etc. The limit on maximum number of characters in method name is 40 and the method name is case-sensitive.

6. There are two routing rules configured to demonstrate how custom HTTP method works.

HTTP MethodHTTP Routing

Rule1: Custom HTTP method is CAT. The Application Load Balancer returns a fixed response static page for any CAT requests for path /arr_method.

Rule2: Custom HTTP method is DOG. The Application Load Balancer returns a fixed response static page for any CDOG requests for path /arr_method.

https://exampleloadbalancer.com/advanced_request_routing_httpmethod_overview.html

Source IP CIDR Based Routing

Source IP CIDRSOURCE IP Routing

1. Let’s imagine that there is a page that is only accessible from your admin network whose IP CIDR is 203.0.113.0/24.

2. When you access the admin page from the admin network, you will see a “Welcome Page”. However, when you access the page from any other IP CIDR, you will get an error page.

HTTP Header based routing (User-Agent Header)

HTTP HeaderHTTP Header routing

1. When you click the button, a HTTP request is sent to the “exampleloadbalancer” Application Load Balancer with the User-Agent information of your browser.
2. There are four routing rules configured on the Application Load Balancer which route request to different target groups based on the User-Agent header (Chrome, Firefox, Safari, IE and Edge).
3. You will see different pages served by the Application Load Balancer when you access the page from the browsers listed above.
4. For each evaluation in a condition, a successful match occurs if the header value matches the match string that is provided as an input including any wildcards in the match string.
5. As you can see from the rule configuration, wildcard “*” (matches 0 or more characters) or a wildcard “?” (matches exactly one character) are supported
Try to click this button from different browsers

In addition, you can read Aws blog on advanced request routing at https://aws.amazon.com/blogs/aws/new-advanced-request-routing-for-aws-application-load-balancers/.

ALB Redirect Feature

Redirect Feature

ALB can redirect HTTP requests to HTTPS. Application Load Balancers support sending HTTP redirects to your clients as an action. This allows you to easily redirect HTTP traffic to your HTTPS, freeing you from running webservers just to perform redirects. You can redirect requests based on any routing rule. If you have an old URI that you don’t want to maintain a redirect for in your application, offload it to the Application Load Balancer!

When a request is sent to the exampleloadbalancer demo site through HTTP with cURL, ALB (Server: awselb/2.0) redirects the request by sending a “HTTP 301 Moved Permanently” response with “Location” header set to the redirected URL which use HTTPS.

Without Redirect

You can try http://exampleloadbalancer.com/

Fixed Response

You can use fixed-response actions to drop client requests and return a custom HTTP response. You can use this action to return a 2XX, 4XX, or 5XX response code and an optional message. A request for the URI is sent to the Application Load Balancer, which normally would route it to one of your targets, but, when you configuring your routing rules to deliver a fixed-response, the load balancer generates the response and sends it directly to the client Your backends do not receive the requests, letting you focus on delivering your application.

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

https://exampleloadbalancer.com/fixed_200

https://exampleloadbalancer.com/fixed_404

https://exampleloadbalancer.com/fixed_599

Application Load Balancers Support Multiple TLS Certificates With Smart Selection Using SNI.

When you create an HTTPS listener, you must specify exactly one certificate. This certificate is known as the default certificate.

If you specify additional certificates in a certificate list, the default certificate is used only if a client connects without using the Server Name Indication (SNI) protocol to specify a hostname or if there are no matching certificates in the certificate list.

If you do not specify additional certificates but need to host multiple secure applications through a single load balancer, you can use a wildcard certificate or add a Subject Alternative Name (SAN) for each additional domain to your certificate. After you create an HTTPS listener, it has a default certificate and an empty certificate list. You can optionally add certificates to the certificate list for the listener. Using a certificate list enables the load balancer to support multiple domains on the same port and provide a different certificate for each domain.

The load balancer uses a smart certificate selection algorithm with support for SNI. If the hostname provided by a client matches a single certificate in the certificate list, the load balancer selects this certificate. If a hostname provided by a client matches multiple certificates in the certificate list, the load balancer selects the best certificate that the client can support. Certificate selection is based on the following criteria in the following order:

• Public key algorithm (prefer ECDSA over RSA)
• Hashing algorithm (prefer SHA over MD5)
• Key length (prefer the largest)
• Validity period

The load balancer access log entries indicate the hostname specified by the client and the certificate presented to the client.

AWS Blog about SNI at https://aws.amazon.com/blogs/aws/new-application-load-balancer-sni/

Demo is at https://exampleloadbalancer.info/sni_demo.html

How to securely publish Internet applications at scale using Application Load Balancer and AWS PrivateLink

Following blog post https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-securely-publish-internet-applications-at-scale-using-application-load-balancer-and-aws-privatelink/?nc1=b_rp

explains How you can combine PrivateLink with Application Load Balancer to publish web applications to the Internet without the need for proxies hosted on EC2 or VPC peering.

AWS Private Link and ELB

How to use AWS PrivateLink to secure and scale web filtering using explicit proxy

Following blog post https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-use-aws-privatelink-to-secure-and-scale-web-filtering-using-explicit-proxy/ explains how you can use AWS PrivateLink to centralize your web filtering solution without using VPC Peering, VPNs or EIP

Proxy with ELB and Privatelink

Lambda Functions as targets

Now let’s dive into lambda functions as target. ALB provide a single HTTP endpoint for all these different compute workloads such as Ec2, containers, Ip addresses and now lambda. Lambda functions as a target to enable event driven serverless computing behind alb. ALB and Lambda functions should belong to the same account.

Taregets as Lambda, Ec2, Onprem

The benefits of lambda functions as targets:

• Build websites as serverless code
• Lambda to manage and run your functions
• ALB as simple HTTP frontend
• Both HTTP and HTTPS protocol
• Use any Lambda supported programming languages
• ALB content based routing rules
• Hybrid applications with mixed compute
• Create custom targets for ALB using serverless e.g. S3

Now let’s look at how to set up lambda functions as targets in alb.

1. Author a Lambda function
2. Create a target group with target type lambda
3. Provide granular permissions to ELB to Invoke your target lambda function
4. Register Lambda function ARN to the target group
5. Associate the target group with a listener rule

You can also create ALB as a trigger in your console. Below is the screenshot.

ALB as Trigger

There is a one cool thing that with the lambda integration with alb. This is health check support in for lambda functions.

Health Checks

It is an optional capability because there is cost associated with health checking for lambda invocations. If you cannot tolerate any downtime for your application. In case your lambda functions have some problem or the downstream dependency that lambda function fetches information from is not working. The way it works is that you will create two applications in US West and US East. Equivalent stacks in both regions. Then you will configure a domain name for your application with DNS failover policy. So essentially, you will create an alias record set in route 53 and set DNS failover for it. Primary fqdn is a primary load balancer. In this case let us say is US East. That will be your fqdn of that will be set as a primary. Then fqdn of the load balancer on US WEST will be secondary. Now DNS failover route 53 will be able to switch over to the load balancer in another region when one region fails. This is how it works so when there is a failure at the lambda function level or at the downstream dependency level. This health check failure will be propagated to throughout route 53. By this notification route 53 will start directing users to the alb in a different region. This will give you highly available application across two different regions. Now there are two important thing that you should also know about.

• What is the structure of the event that alb invokes have?
• What is the content that you get to your lambda function when alb invokes them?

Invoke Events

{ 
 “requestContext”:{ 
 “elb”:{ 
 “targetGroupArn”:”arn:aws:elasticloadbalancing:region:123456789012:targetgroup/my-target-group/6d0ecf831eec9f09"
 }
 },
 “httpMethod”:”GET”,
 “path”:”/”,
 “queryStringParameters”:{ parameters },
 “headers”:{ 
 “accept”:”text/html,application/xhtml+xml”,
 “accept-language”:”en-US,en;q=0.8",
 “content-type”:”text/plain”,
 “cookie”:”cookies”,
 “host”:”lambda-846800462-us-east-2.elb.amazonaws.com”,
 “user-agent”:”Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)”,
 “x-amzn-trace-id”:”Root=1–5bdb40ca-556d8b0c50dc66f0511bf520",
 “x-forwarded-for”:”72.21.198.66",
 “x-forwarded-port”:”443",
 “x-forwarded-proto”:”https”
 },
 “isBase64Encoded”:false,
 “body”:”request_body”
 }

This is a JSON structure of invoke event. You get a target group ARN that you can use for context. Then you will get all the information of the original request from the client. Like HTTP method, path, query string parameters, all the headers and the body. There is a flag called isBase64Encoded with value being could be false or true. This flag indicates whether alb converted the binary body received from the client to the base64 encoding before sending it to your lambda function. There are some typical content type for which can send the body as it is. But for other content type it is sent as Base64Encoded and accordingly the flag is set to 304.

Expected Response from Lambda Function

{
  "isBase64Encoded": false,
  "statusCode": 200,
  "statusDescription": "OK",
  "headers": {
    "Set-cookie": "cookies",
    "Content-Type": "text/html; charset=utf-8"
  },
  "body": "Hello from Lambda (optional)"
}

This is the structure in JSON of what is expected as a response from lambda function. The only mandatory field is status code. Nevertheless, you could form the whole response as you desire. With the kind of information, you want to put into the response header that needs to be sent to the client back. If you need to send binary body to ALB, even base64 encoded, and then JSON serialize it, then send it, and accordingly mark the flag. ALB knows what type of content is it.

Let’s look at the limits. The limit is 1 megabyte and this limit is only for the body.

• Request body ALB ==>Lambda function <=1 MB
• Response Lambda function ==> ALB <=1 MB

There is a limit of 64 kilobytes for the headers, which generally applies to any target type. 1 MB limit is for the whole JSON response that you form. There is no change to the hourly price of ALB. The load balancer capacity units (LCUs) of ALB now include 0.4 GB per hour of processed bytes for Lambda functions as targets. Usual AWS Lambda charges apply.

Authentication on ALB

It is a facility to authenticate your users for your application so that you do not need to take care of that in your application. Applications can focus on the business logic and authentication part can be offloaded to alb. There are two ways:

Native integration with any OpenID Connect compliant (OIDC) Identity Provider (Idp)
• Bring your own IdP
Seamless integration with Amazon Cognito
• Authenticate with corporate identities using LDAP or OIDC
• Authenticate with social identity providers (Facebook, Google, Amazon)

Authentication on ALB

1. User sends HTTP request to a website hosted behind Auth enabled ALB
2. ALB checks for session cookie and redirects the user to IdP if session cookie is missing
3. After authenticating with IdP, user is redirected to ALB with Authorization CODE
4. ALB authenticates the CODE and sends to token endpoint
5. ALB receives JWT token (ID token, Access Token)
6. ALB sends access token to User_Info endpoint
7. ALB receives user claims
8. ALB redirects the user with a session cookie to original URI AWSELBAuthSessionCookie. User make requests to URI with AWSELBAuthSessionCookie.
9. ALB validates cookie and forwards user info to backends “X-AMZN-OIDC-*” HTTP headers set
10. Backends send response back to the ALB
11. ALB sends final response to client

Let’s look at the authentication flow where alb handshake with your OIDc compliant IDP. In this example, Mysite.com runs a video application and you want to access it with authentication. Now let’s see what happens step by step.

1. User sends HTTP requests to watch video
2. This is the first request and user does not have a session cookie that alb looks for so alb will redirect this request of the user to the IDP
3. User enter username and password at IDP portal. At that point, an authorization code issued so the user redirected back to alb.
4. ALB authenticates the code and sends it to the token endpoint
5. ALB receives JWT token in exchange from the token endpoint
6. Alb sends access token which is part of the JWT token to the user_info endpoint to get the user claim
7. ALB Receives user claims
8. ALB redirects the user with a session cookie to the original URL that user wanted to access. User comes back to the origin URI with the cookie this time.
9. Alb will validate this cookie and then forward the request to the target or the application including the info related to the user that was received from the IDP in the form of HTTP headers
10. Application (Targets) will send response back to the alb
11. ALB forwards response to the client

It is important to explain how to configure each of these integrations so let’s look at the native OIDC configuration.

OIDC Configuration

Here you configure the IDP endpoint, which is a URL by itself. Then all the endpoints that we talked about at the token endpoint, authorization endpoint and user info endpoint. The next two parameters are client ID and client secret. These parameters help IDP to authenticate alb. The trusted entity to do this handshake with IDP. Then you have session cookie name. There is a default cookie name that could work but if you are using multiple IDPs then you need to configure one for each. There is a default session timeout cookie of seven days. The range is one second to seven day. The scope is basically the parameter that tells the IDP what’s the level of detail IDP needs to provide during this handshake. Then you have different options in addition to authenticate or requests which are unauthenticated. What to do in that case so you could have option of deny and allow to support. Typically JavaScript’s use cases or single page application with JavaScript.

Here is the demo

https://exampleloadbalancer.auth.us-east-1.amazoncognito.com/login?client_id=6chta8di2d737altiugnidsoq9&redirect_uri=https%3A%2F%2Fexampleloadbalancer.com%2Foauth2%2Fidpresponse&response_type=code&scope=openid&state=m49cV47xfFwY0tmKlrFiw%2BiRGAn08GficOL%2BA3H3t%2FI8k2X%2FcRkktCoQGFnD8qi%2FF4N0j0P2N%2FMtSyVtPdGJOBmgl2rIDzTCyLkfBGdLSObWbMx27G8GJFosr0fy9aIEfQDfmtydOAoYCbyxo8ZbOjaION2c4WLlUV8AtnBD3TB%2FeGzV5CNgl4tnerF1D5Ss2GPbJ5gUlHec0FX0bA%3D%3D

Now let’s look at the Amazon cognito based integration. Most of the parameters are same. The only thing which is different here is that instead of IDP endpoints now you will basically configure the user pool. Which is basically userpool ID that you have in Cognito configuration. The client ID for the cognito user pool and then userpool domain and the rest of the parameters are same.

Cognito Configuration

Below is the information it received by your application targets.

• x-amzn-oidc-accesstoken: Access token from the token endpoint (plain text)
• x-amzn-oidc-identity: Subject field from the user info endpoint (plain text)
• x-amzn-oidc-data: User claims in JWT format (base64 URL encoded and includes signature)

Header

{ 
"alg": "algorithm", 
"kid": "12345678-1234-1234-1234-123456789012", 
"signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", 
"iss": "url", 
"client": "client-id",
"exp": "expiration“
}

Payload

You can have demo at https://exampleloadbalancer.com/auth_demo.html