Entra ID on HabibiOps

AWS ALB Federated OIDC with Cognito and Entra ID

Wed, 24 Jun 2026 00:00:00 +0000

Introduction

In the previous post, we talked about how to configure the AWS ALB listener for Entra ID OIDC authentication. We noticed that the ALB does not forward the ID token that contains the user’s group memberships to the backend. The ALB forwards the access token as x-amzn-oidc-accesstoken. It generates new JWTs as headers called x-amzn-oidc-data and x-amzn-oidc-identity that contain the user claims from the user info endpoint and the subject field (sub) respectively. The Entra ID user info endpoint does not return any group memberships of the user and hence the need for some alternatives to get the groups claim. We discussed using the Graph API to get the groups in the last post, and today we will discuss how to use Cognito configured with Entra ID as the OIDC provider for the ALB.

Configure ALB Entra ID OIDC Federation with Cognito

Below is the terraform code snipper to create a new Cognito User Pool with an Entra ID OIDC client. In addition, we map the attributes that we want to forward to the backend application to a new custom attribute. We mapped the most important claims such as sub, name, email, groups, and roles to custom attributes. Since Entra ID is used to manage the users, we should disable the user sign-up feature in Cognito when we create the user pool.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


locals {
 tenant_id = "<Azure_AD_tenant_ID>"
 microsoft_login_url = "https://login.microsoftonline.com/${local.tenant_id}"
 authorization_endpoint = "${local.microsoft_login_url}/oauth2/v2.0/authorize"
 issuer = "${local.microsoft_login_url}/v2.0"
 token_endpoint = "${local.microsoft_login_url}/oauth2/v2.0/token"
 user_info_endpoint = "https://graph.microsoft.com/oidc/userinfo"
 scope = "openid profile email"
 client_id = "<FETCH_FROM_AZURE_APP_REGISTRATION>"
 client_secret = "<FETCH_FROM_SECRET_MANAGER>"
 certificate_arn = "<FETCH_FROM_ACM>"
 cognito_user_pool_schema_names = [
 "sub",
 "name",
 "aud",
 "iss",
 "iat",
 "nbf",
 "exp",
 "email",
 "groups",
 "idp",
 "name",
 "oid",
 "preferred_username",
 "roles",
 "sid",
 "sub",
 "tid",
 "ver",
 ]
 attribute_mapping = {
 email = "preferred_username"
 username = "sub"
 name = "name"
 "custom:aud" = "aud"
 "custom:iss" = "iss"
 "custom:iat" = "iat"
 "custom:nbf" = "nbf"
 "custom:exp" = "exp"
 "custom:email" = "email"
 "custom:groups" = "groups"
 "custom:idp" = "idp"
 "custom:name" = "name"
 "custom:oid" = "oid"
 "custom:preferred_username" = "preferred_username"
 "custom:roles" = "roles"
 "custom:sid" = "sid"
 "custom:sub" = "sub"
 "custom:tid" = "tid"
 "custom:ver" = "ver"
 }
}

resource "aws_cognito_user_pool" "entraid" {
 name = "entraid-oidc-pool"
 dynamic "schema" {
 for_each = toset(local.cognito_user_pool_schema_names)
 content {
 attribute_data_type = "String"
 developer_only_attribute = false
 mutable = true
 name = schema.value
 required = false
 string_attribute_constraints {}
 }
 }
}

resource "aws_cognito_identity_provider" "entra_oidc" {
 user_pool_id = aws_cognito_user_pool.entraid.id
 provider_name = "EntraID"
 provider_type = "OIDC"

 provider_details = {
 authorize_scopes = "openid profile email"
 attributes_request_method = "GET"
 oidc_issuer = local.issuer
 authorize_url = local.authorization_endpoint
 token_url = local.token_endpoint
 attributes_url = local.user_info_endpoint
 client_id = local.client_id
 client_secret = local.client_secret
 }

 attribute_mapping = local.attribute_mapping
}

Note that there is a 2048 char limit for mapped Cognito custom attributes!

After creating all the Cognito resources, we can now configure the ALB listener to use Cognito for OIDC authentication. The below is the terraform code snippet for configuring the HTTPS listener:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


resource "aws_lb_listener" "https" {
 load_balancer_arn = aws_lb.alb.arn
 port = 443
 protocol = "HTTPS"
 ssl_policy = "ELBSecurityPolicy-TLS13-1-2-Res-2021-06"
 certificate_arn = local.certificate_arn

 default_action {
 type = "authenticate-cognito"

 authenticate_cognito {
 user_pool_arn = aws_cognito_user_pool.entra_pool.arn
 user_pool_client_id = aws_cognito_user_pool_client.entra_client.id
 user_pool_domain = aws_cognito_user_pool_domain.entra_domain.domain
 }
 }

 default_action {
 type = "forward"
 target_group_arn = aws_lb_target_group.backend.arn
 }
}

Don’t forget to update the app registration call back URIs with the auth one from Cognito!

Now the ALB listener is configured to use Cognito for OIDC authentication, and Cognito is configured to use Entra ID. Once a user authenticates, the ALB listener forwards the request to Cognito. Cognito then redirects the user to Entra ID. Once the user enters their credentials correctly, Entra ID issues the tokens and redirects the user back to Cognito. Cognito maps the custom attributes that we configured in the Cognito user pool to the custom attributes that we want to forward to the backend application. The ALB listener now adds these custom attributes to the x-amzn-oidc-data header JWT that will be forwarded to the backend application. Below is the ALB Cognito authentication sequence diagram:

sequenceDiagram
participant User as User (Browser)
participant ALB as AWS ALB (HTTPS Listener)
participant Cognito as Cognito User Pool
participant Entra ID as Entra ID (Azure AD)
participant Backend as Backend (Application)
User ->> ALB: Request resources
ALB ->> Cognito: Cognito OIDC authentication
Cognito ->> Entra ID: Entra ID OIDC authentication
Entra ID -->> Cognito: ID and Access Tokens from Microsoft
Cognito -->> ALB: Cognito tokens with group memberships such as "custom:roles"
ALB ->> Backend: ALB x-amzn-oidc-* tokens now contain group memberships via custom:* attributes
Backend -->> User: Authorize user according to group memberships
Note right of Cognito: Cognito custom attributes mapping:<br/>"custom:roles" = "roles"<br/>"custom:groups" = "groups"<br/>etc. (additional custom attributes)

Architecture Diagram

Here is the architecture diagram for the above setup:

The user sends an HTTPS request to the ALB listener.
The ALB checks the encrypted AWSELBAuthSessionCookie to see if the user is authenticated.
If the user is authenticated and the credentials have not expired, the ALB forwards the request to the backend application.
If the user is not authenticated, the ALB redirects to Cognito.
Cognito redirects the user to Entra ID.
Entra ID issues the ID and access tokens and redirects the user back to Cognito.
Cognito issues new ID and access tokens where the custom attributes that we configured in the Cognito user pool are mapped to the Microsoft ID token claim that we want to forward to the backend application.
The ALB listener adds these custom attributes to the x-amzn-oidc-data header JWT that will be forwarded to the backend application.
The ALB forwards the request to the backend application.

Debugging ALB Headers

We mapped one of the ALB target groups to a Lambda function that prints the headers that are forwarded to the backend application. The below is the Lambda function code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


export const handler = async (event) => {
 if (event.path === "/health") {
 return {
 statusCode: 200,
 statusDescription: "200 OK",
 isBase64Encoded: false,
 headers: {
 "content-type": "application/json"
 },
 body: JSON.stringify({status: "ok"})
 };
 }

 const response = {
 statusCode: 200,
 statusDescription: "200 OK",
 isBase64Encoded: false,
 headers: {
 "content-type": "application/json"
 },
 body: JSON.stringify({
 message: "Hello from Lambda!",
 headers: event.headers
 }, null, 2),
 };

 return response;
};

Here is the browser Lambda function response containing all the headers that are forwarded to the backend application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


{
 "message": "Hello from Lambda!",
 "headers": {
 "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
 "accept-encoding": "gzip, deflate, br, zstd",
 "accept-language": "en-GB,en;q=0.9",
 "cache-control": "max-age=0",
 "cookie": "AWSALBAuthNonce=yRxRypFZxo6WVJ5r",
 "host": "myapp.aws.cloud",
 "priority": "u=0, i",
 "referer": "https://login.microsoftonline.com/",
 "sec-ch-ua": "\"Opera\";v=\"131\", \"Not.A/Brand\";v=\"8\", \"Chromium\";v=\"147\"",
 "sec-ch-ua-mobile": "?0",
 "sec-ch-ua-platform": "\"macOS\"",
 "sec-fetch-dest": "document",
 "sec-fetch-mode": "navigate",
 "sec-fetch-site": "cross-site",
 "sec-fetch-user": "?1",
 "upgrade-insecure-requests": "1",
 "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36 OPR/131.0.0.0",
 "x-amzn-oidc-accesstoken": "eyJra..",
 "x-amzn-oidc-data": "eyJ0..",
 "x-amzn-oidc-identity": "6a39920f-22f1-80c5-a800-5ff93f246878",
 "x-amzn-trace-id": "Root=1-93745822-6b42af092447ea692bdc5848",
 "x-forwarded-for": "MY_IP_ADDRESS",
 "x-forwarded-port": "443",
 "x-forwarded-proto": "https"
 }
}

Let’s check the x-amzn-oidc-data header to see if the custom attributes that we mapped from the Microsoft ID token claims are forwarded to the backend application. Here is a decoded x-amzn-oidc-data JWT:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{
 "typ": "JWT",
 "kid": "bc1052be-9015-45ab-9cd0-d59f70cd3d58",
 "alg": "ES256",
 "iss": "https://login.microsoftonline.com/AZURE_AD_TENANT_ID/v2.0",
 "client": "Azure_Application_Client_ID",
 "signer": "arn:aws:elasticloadbalancing:eu-central-1:123456789012:loadbalancer/...",
 "exp": 1782336016
}.{
 "sub": "...",
 "email_verified": "false",
 "custom:nbf": "Wed Jun 24 20:55:55 UTC 2026",
 "custom:preferred_username": "email@domain.com",
 "custom:aud": "[Azure_Application_Client_ID]",
 "custom:tid": "AZURE_AD_TENANT_ID5",
 "custom:oid": "44df6ec6-99d3-4816-8e87-f4f58dc93194",
 "custom:groups": "[\"bfb757fa-2c21-4b60-98f2-a1e0fd6c1435\"]",
 "custom:ver": "2.0",
 ...
}.[
 Signature
]

All the custom attributes that we mapped from the Microsoft ID token claims are now forwarded to the backend application. We used Cognito as a federated OIDC provider for the ALB listener.

Conclusion

In this post, we discussed how to configure the AWS ALB listener to use Cognito for OIDC authentication and how to configure Cognito to map custom attributes from the Microsoft ID token claims to be forwarded to the ALB tokens. This solved the problem of the disappearing ID token along with its group memberships claim that can be used by the backend for AuthZ as described in the first post.

Microsoft ID token with claims
|
| (e.g. groups)
V
Cognito idToken with custom attributes mapping
|
| (e.g. "custom:groups" = "groups")
V
ALB x-amzn-oidc-data token with custom:groups and other custom attributes
|
| x-amzn-oidc-* tokens forwarded
V
Backend application receives all mapped custom attributes

References:

AWS ALB OIDC with Entra ID

Thu, 11 Jun 2026 00:00:00 +0000

Introduction

I do not want my app to perform OIDC, and I do not want unauthenticated traffic reaching my private subnets. I have a simple React SPA, and when keeping these prerequisites in mind would lead us to perform OIDC authentication using native AWS services. This can be at best done with the application load balancer (ALB). The ALB can be configured to perform OIDC authentication at the listener level. Sounds great, but like everything in life, there are some gotchas..

AWS ALB Entra ID OIDC Authentication

Let’s configure the HTTPS ALB listener to perform Entra ID OIDC authentication. As a prerequisite, we assume that you have already configured an Azure App Registration. This is a terraform snippet that shows the ALB listener configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


locals {
 tenant_id = "<Azure_AD_tenant_ID>"
 microsoft_login_url = "https://login.microsoftonline.com/${local.tenant_id}"
 authorization_endpoint = "${local.microsoft_login_url}/oauth2/v2.0/authorize"
 issuer = "${local.microsoft_login_url}/v2.0"
 token_endpoint = "${local.microsoft_login_url}/oauth2/v2.0/token"
 user_info_endpoint = "https://graph.microsoft.com/oidc/userinfo"
 scope = "openid profile email"
 client_id = "<FETCH_FROM_AZURE_APP_REGISTRATION>"
 client_secret = "<FETCH_FROM_SECRET_MANAGER>"
 certificate_arn = "<FETCH_FROM_ACM>"
}

resource "aws_lb_listener" "https" {
 load_balancer_arn = aws_lb.alb.arn
 port = 443
 protocol = "HTTPS"
 ssl_policy = "ELBSecurityPolicy-TLS13-1-2-Res-2021-06"
 certificate_arn = local.certificate_arn

 default_action {
 type = "authenticate-oidc"
 authenticate_oidc {
 authorization_endpoint = local.authorization_endpoint
 client_id = local.client_id
 client_secret = local.client_secret
 issuer = local.issuer
 token_endpoint = local.token_endpoint
 user_info_endpoint = local.user_info_endpoint
 scope = local.scope
 }
 }

 default_action {
 type = "forward"
 target_group_arn = aws_lb_target_group.backend.arn
 }
}

That’s it! Now you can access your application, and all HTTPS requests will be redirected to the Entra ID login page. After successful authentication, the user will be redirected back to the application as indicated in the target group arn target_group_arn = aws_lb_target_group.backend.arn. The callback URLs or redirect URIs configured for the application are: https://myapp.aws.cloud/oauth2/idpresponse.

All the above details for OIDC are available in the well-known endpoint that is a standardized JSON file containing the metadata such as the issuer, authorization endpoint, token endpoint, user info endpoint, etc. The well-known endpoint for Entra ID is available at the following URL: https://login.microsoftonline.com/<Azure_AD_tenant_ID>/.well-known/openid-configuration

Where is my ID token?

If you have done Entra ID OIDC authentication before, you would be used to receiving the ID, access, and refresh tokens back from the corresponding Microsoft endpoints. However, the AWS ALB does not return all of these tokens! The ALB only returs the original access token mapped to a header called x-amzn-oidc-accesstoken. It does not return the original ID token that it received from Entra ID. It is important to know this information beforehand if the system depends on the ID tokoen for authorization as well in addition to authentication since it contains the group memberships of the user as a claim called groups. The AWS ALB generates a separate JWT instead called x-amzn-oidc-data that contains the user claims received from the IdP user info endpoint and is signed by the ALB itself. The ALB forwards the x-amzn-oidc-* headers to its target group:

x-amzn-oidc-accesstoken: The access token from the token endpoint.
x-amzn-oidc-identity: The subject field (sub) from the user info endpoint.
x-amzn-oidc-data: The user claims, in JSON web tokens (JWT) format.

According to the official documentation: The Application Load Balancer creates a new access token when authenticating a user and only passes the access tokens and claims to the backend, however it does not pass the ID token information.

AWS ALB AuthN and Backend AuthZ

Since we are managing users in Entra ID, we also manage their group memberships there and can use these group memberships to authorize (AuthZ) the user in our app. The AWS ALB is responsible for authenticating (AuthN) the user, but not for authorizing (AuthZ) it. What is missing in the ALB tokens that would allow our backend to do AuthZ using Entra ID? It is the group memberships of the user that is present in the original ID token as a roles or groups claim.

The roles and groups claims that our backend application needs is not passed to the ALB x-amzn-oidc-data since the ALB fetches the user claims from the user info endpoint. The Entra ID user info endpoint does not return the group memberships of the user. This means that the backend application does not receive any information about the Entra ID group memberships of the logged-in user and cannot decide if the user has admin or developer permissions, for example.

Here is an example of a decoded x-amzn-oidc-data JWT that contains the user claims:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{
 "typ": "JWT",
 "kid": "bc1052be-9015-45ab-9cd0-d59f70cd3d58",
 "alg": "ES256",
 "iss": "https://login.microsoftonline.com/<Azure_AD_tenant_ID>/v2.0",
 "client": "<Azure_Application_Client_ID>",
 "signer": "arn:aws:elasticloadbalancing:eu-central-1:123456789012:loadbalancer/app/demo/f88f43ca1f389b69",
 "exp": 1782336913
}.{
 "sub": "(same value as x-amzn-oidc-identity)",
 "name": "Firstname Lastname",
 "family_name": "Lastname",
 "given_name": "Firstname",
 "picture": "https://graph.microsoft.com/v1.0/me/photo/$value",
 "email": "email@domain.com",
 "exp": 1782336913,
 "iss": "https://login.microsoftonline.com/<Azure_AD_tenant_ID>/v2.0"
}.[
 Signature
]

The ALB signed the token as shown in the signer claim in the header but Entra ID issued it as shown in the iss claim. The payload contains the name and email address of the user but no information about the group memberships.

The x-amzn-oidc-access header contains the access token and the x-amzn-oidc-identity header contains the subject field (sub) which is already present in x-amzn-oidc-data.

Here is a decoded ID token retrieved directly from Entra ID after successful authentication:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


{
 "typ": "JWT",
 "alg": "RS256",
 "kid": "Xt-o7hDbpupAz-ZPm6HxCFWS3cI"
}.{
 "aud": "AZURE_APP_REGISTRATION_CLIENT_ID",
 "iss": "https://login.microsoftonline.com/AZURERM_TENANT_ID/v2.0",
 "iat": 1779217576,
 "nbf": 1779217576,
 "exp": 1779221476,
 "email": "email@domain.com",
 "groups": [
 "7290ecbc-ce9e-118b-9c11-7811fc885ef3",
 "490fbb8c-ecff-4c80-7a0d-1c76a112c6dc"
 ],
 "idp": "https://sts.windows.net/AZURERM_TENANT_ID/",
 "name": "Firstname Lastname",
 ...
 "roles": [
 "MYAPP1.READONLY",
 "MYAPP2.WRITESOMEDATA",
 "MYAPP3.ADMIN"
 ],
 ...
 "tid": "AZURERM_TENANT_ID",
 ...
 "ver": "2.0"
}.[
 Signature
]

Notice the groups claim that contains the group memberships of the user as group IDs in addition to the roles claim that contains the mapped roles of the user.

User Group Memberships

We need to get the group memberships of the user in order to authorize the user in our backend application. Here is a sequence diagram of the problem definition:

sequenceDiagram
User ->> ALB: Authenticate
ALB ->> Entra ID: Entra ID authentication
Entra ID -->> ALB: ID and Access Tokens
Note right of Backend: ALB creates its own tokens x-amzn-oidc-*
ALB ->> Backend: x-amzn-oidc-accesstoken, x-amzn-oidc-identity, x-amzn-oidc-data
Backend --x User: admin user or developer? Missing group memberships in x-amzn-oidc-data

We have two practical possible solutions that can be used to get the group memberships of the user:

call the Graph API from the backend using the original access token
use Cognito federated OIDC with custom attributes mapped to the groups claim in the ID token

Group Memberships from the Graph API using the Backend

One way to get the group memberships of the user is to use the Microsoft Graph API. Since the ALB returns the x-amzn-oidc-accesstoken header that contains the original access token, we can use it to call the Microsoft Graph API. Namely, we can call the List member of endpoint to get the group memberships of the current user as shown in the sequence diagram below:

sequenceDiagram
User ->> ALB: Authenticate
ALB ->> Entra ID: Entra ID authentication
Entra ID -->> ALB: ID and Access Tokens
ALB ->> Backend: x-amzn-oidc-accesstoken, x-amzn-oidc-identity, x-amzn-oidc-data
Note right of Backend: Use x-amzn-oidc-accesstoken for Graph API call
Backend ->> Graph API: GET /me/memberOf
Graph API -->> Backend: User Groups
Backend -->> User: Authorize user according to group memberships

Here is an example of a decoded x-amzn-oidc-accesstoken JWT that contains the original access token issued by Entra ID:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


{
 "typ": "JWT",
 "nonce": "5pAPQQajdTfmT3N0jazjZvaI0NNWKX4gP4Zxm2T7p4M",
 "alg": "RS256",
 "x5t": "aFkmKVFc-4WV6sXCBvNZkXI505Y",
 "kid": "aFkmKVFc-4WV6sXCBvNZkXI505Y"
}.{
 "aud": "00000003-0000-0000-c000-000000000000",
 "iss": "https://sts.windows.net/AZURERM_TENANT_ID/",
 "iat": 1782336493,
 "nbf": 1782336493,
 "exp": 1782341108,
 ...
 "app_displayname": "AZURE_APP_REGISTRATION",
 "appid": "AZURE_APP_REGISTRATION_CLIENT_ID",
 "appidacr": "1",
 "family_name": "Lastname",
 "given_name": "Firstname",
 "idtyp": "user",
 "ipaddr": "...",
 "name": "Firstname Lastname",
 ...
 "scp": "email openid profile User.Read",
 ...
 "tid": "AZURERM_TENANT_ID",
 "unique_name": "email@domain.com",
 "upn": "email@domain.com",
 ...
}.[
 Signature
]

Here’s the response from the user info endpoint fromm where the ALB retrieves the user claims:

1
2
3
4
5
6
7
8
9


curl -H "Authorization: Bearer $ACCESS_TOKEN" https://graph.microsoft.com/oidc/userinfo | jq

{
 "sub": "...",
 "name": "Firstname Lastname",
 "family_name": "Lastname",
 "given_name": "Firstname",
 "picture": "https://graph.microsoft.com/v1.0/me/photo/$value"
}

Here’s an example of a call to the Graph API to get the basic information of the current user:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


curl -H "Authorization: Bearer ${x-amzn-oidc-accesstoken}" https://graph.microsoft.com/v1.0/me/ | jq

{
 "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
 "businessPhones": [],
 "displayName": "username",
 "givenName": "Firstname",
 "jobTitle": null,
 "mail": null,
 "mobilePhone": null,
 "officeLocation": null,
 "preferredLanguage": null,
 "surname": "Lastname",
 "userPrincipalName": "email@domain.com",
 "id": "45de6ef6-99d3-4816-8e87-d4c58da93195"
}

Here’s an example of a call to the Graph API to get the group memberships of the current user:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


curl -H "Authorization: Bearer ${x-amzn-oidc-accesstoken}" https://graph.microsoft.com/v1.0/me/memberOf | jq

{
 "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
 "value": [
 {
 "@odata.type": "#microsoft.graph.group",
 "id": "96e87c46-5e04-4811-83f4-529925f7cad3",
 ...
 },
 {
 "@odata.type": "#microsoft.graph.group",
 "id": "c5643819-f668-4cd5-8420-9dd925efc071",
 ...
 },
 ...
 ]
}

The response contains a list of maps that contain the group ID and some other information of the group. One can also cache the results for 5 to 10 minutes using a DynamoDB table. This way, a new request to the Graph API would only take place in case of a cache lookup miss in DynamoDB. Keep in mind that this means any changes to the group memberships of the user inside Entra ID will not be reflected in the application until the cache is cleared after 5 or 10 minutes.

Group Memberships using Cognito Federated OIDC

This is addressed in our second blog post on this topic.

Misc.

Here are some important miscellaneous topics to consider when dealing with ALB authentication.

ALB JWT Signature Verification

The backend has to verify the signature of the ALB JWTs before doing any authorization based on the claims. Validate that the signer field contains the expected ALB ARN. You can also use AWS JWT Verify

AWSELBAuthSessionCookie

The ALB creates an encrypted cookie named AWSELBAuthSessionCookie after successful authentication. If the cookie is present and valid, the ALB will not authenticate the user again. Otherwise, the ALB will redirect the user to the authentication page. Only the ALB can decode the cookie data, and the user cannot not see any meaningful information in the cookie. Here is an example of the cookie value with some content in the middle redacted:

1

9VYTnUxOk5E8mpOG5LX5H5BeDvn05VC84PZ7nWgaNuu0ib129DTdwl1QguLpgINiK8x41ZK1rc3WtHsLnu/...Kygcam4PFLY1akYbNDNAaupFDIJg2poeN3EF0AQ1NWWBxbYYMB0A8d

ALBeast Security Bypass

We have seen in the previous section a decoded x-amzn-oidc-data JWT:

it was signed by the ALB
it was issued by Entra ID
it did not contain an aud claim

This has led to the discovery of ALBeast. More information can be found here.

In order to make sure that you are not a victim of this vulnerability:

make sure that the ALB targets accept traffic only from the ALB by referencing the ALB security group in the inbound rules of the target security group
implement signature validation for the ALB JWT and confirm the signature by your ALB ARN

An official AWS spokesperson response to this according to The Hacker News:

It is incorrect to call this an authentication and authorization bypass of AWS Application Load Balancer (ALB) or any other AWS service because the technique relies on a bad actor already having direct connectivity to a misconfigured customer application that does not authenticate requests. We recommend customers configure their applications to only accept requests from their ALB by using security groups and by following the ALB security best practices. A small fraction of a percent of AWS customers have applications potentially misconfigured in this way, significantly fewer than the researchers’ estimate. We have contacted each one of these customers directly to share best practices for configuring applications which use ALB.

Conclusion

In this post, we have seen how to configure Entra ID OIDC authentication for an AWS ALB listener. We have also seen one way on how to get the group memberships of the user in the backend application by using the Microsoft Graph API. In part 2 of this series, we will see how to use Cognito Federated OIDC to achieve the same result. We also discussed some miscellaneous security topics that need to be considered.

References: