If you're setting up AWS Cognito as a Generic OIDC provider in Qlik Cloud and wondering why your users have no groups even though everything looks correctly configured — this is the post I wish existed when I hit this wall.

The problem

Qlik Cloud reads user claims from Cognito's userinfo endpoint. The userinfo endpoint does not return cognito:groups. It doesn't error. It just returns nothing for groups, silently.

You can confirm this yourself. After logging in, hit:

GET https://{your-tenant}/api/v1/diagnose-claims

You'll see "claimSource": "idp-userinfo" and claimsFromIdp with no group information at all. The cognito:groups claim exists in the ID token, but Qlik never reads the ID token — it reads userinfo, and userinfo doesn't carry it. No amount of adjusting the groups field in the Qlik IdP configuration will change that.

What actually works

The fix is a Post Authentication Lambda that writes the user's Cognito group memberships into a custom:groups user attribute on every login. Unlike cognito:groups, custom attributes ARE returned by the userinfo endpoint. Qlik picks them up normally.

Here's the full setup:

Step 1 — Add a custom:groups attribute to your User Pool

In the AWS Console: Cognito → User Pools → {your pool} → Sign-in experience → User attributes → Custom attributes → Add custom attribute

⚠️ Custom attributes are permanent in Cognito. You cannot delete them after creation.

Step 2 — Grant your Qlik Cloud app client Read access to custom:groups

App clients → {your Qlik Cloud app client} → Attribute read and write permissions → custom:groups → Read ✅

Step 3 — Create the Lambda

Runtime: Node.js 22.x. No extra dependencies — the AWS SDK is included in the runtime.

import {
  CognitoIdentityProviderClient,
  AdminListGroupsForUserCommand,
  AdminUpdateUserAttributesCommand
} from "@aws-sdk/client-cognito-identity-provider";

const client = new CognitoIdentityProviderClient({ region: process.env.AWS_REGION });

export const handler = async (event) => {
  const { userPoolId, userName } = event;

  const groupsResponse = await client.send(
    new AdminListGroupsForUserCommand({ UserPoolId: userPoolId, Username: userName })
  );

  const groups = groupsResponse.Groups.map((g) => g.GroupName).join(",");

  await client.send(
    new AdminUpdateUserAttributesCommand({
      UserPoolId: userPoolId,
      Username: userName,
      UserAttributes: [{ Name: "custom:groups", Value: groups }],
    })
  );

  return event; // Post Authentication triggers must return event unchanged
};

Step 4 — IAM permissions for the Lambda role

Inline policy on the Lambda execution role, scoped to your specific user pool:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "cognito-idp:AdminListGroupsForUser",
      "cognito-idp:AdminUpdateUserAttributes"
    ],
    "Resource": "arn:aws:cognito-idp:{REGION}:{ACCOUNT_ID}:userpool/{USER_POOL_ID}"
  }]
}

Step 5 — Register as a Post Authentication trigger

User Pool → Extensions → Lambda triggers → Authentication → Post authentication → Add Lambda trigger

If you have a Pre-token generation trigger from an earlier attempt to inject groups into the ID token, remove it. It won't help and may cause side effects.

Step 6 — Update the Qlik Cloud IdP

Administration → Identity Providers → {your Cognito IdP} → Edit → Claims mapping:

Change groups from cognito:groups → custom:groups

Qlik Cloud parses the comma-separated value automatically.

Verify it worked

Log out, log back in, then check diagnose-claims again. You should now see:

{
  "claimSource": "idp-userinfo",
  "claimsFromIdp": {
    "custom:groups": "GroupA,GroupB"
  },
  "mappedClaims": {
    "groups": ["GroupA", "GroupB"]
  }
}

Groups will also appear in Administration → Groups after the first login.

Quick troubleshooting

Hope this saves someone a few hours. Tested and working on Qlik Cloud with a Generic OIDC Cognito setup.