Forge the Group Claim: Escalating to Admin via cognito:groups
The challenge
This cloud app authorises admin actions from a nested group claim in your JWT, the Cognito-style cognito:groups array. You are in the users group, but the backend reads that array straight from the token and never verifies the signature. In the workbench, edit the payload so cognito:groups becomes ["admins"]. Mind the JSON: it is an array of strings, so keep the brackets and quotes intact. Copy the whole forged token and submit it.
What you'll learn
- Understand how cloud providers embed group membership in JWT claims
- Edit a nested array claim while keeping the JSON structurally valid
- Forge admin access by changing cognito:groups from users to admins
- Recognise unverified group claims as a critical authorization flaw
- Know that authorization must derive from a signature-verified token
Skills tested
Prerequisites
- A JWT is three base64url parts: header, payload, signature
- Claims can be nested, including arrays of strings
- Basic JSON editing
How it works
Cloud identity systems such as Amazon Cognito attach a user's groups to their token as a nested claim, conventionally cognito:groups, whose value is an array of group names. Applications then map those groups to permissions: if the array contains admins, grant admin. This works only when the token's signature has been verified against the identity provider's key, because that verification is what proves the group list came from the provider and was not edited by the holder.
This backend reads the array but never verifies the signature, so the JWT is just editable JSON. The challenge over a flat claim is that the target is nested and structured: {"cognito:groups":["users"]}. You must change ["users"] to ["admins"] while keeping it a valid JSON array of strings - the square brackets and the double quotes around the string have to stay, or the payload will not parse. The workbench re-encodes the corrected payload and rebuilds the token, carrying the original (now invalid) signature, which the server ignores.
The result is a token that claims membership in admins and is accepted as such. The flaw is identical in spirit to a flat role forge - the only added difficulty is editing nested structure cleanly.
Common mistakes
- Breaking the JSON structure.
cognito:groupsis an array of strings; keep the brackets and quotes, for example["admins"], notadminsbare. - Editing the wrong claim. Authorization keys on the group array, not on
suboremail. - Trying to fix the signature. No valid signature is needed here; the server never verifies it.
- Submitting the decoded JSON. Submit the rebuilt, re-encoded token (or its payload segment), not the human-readable claims.
How to defend against it
Group-based authorization is only as strong as the token verification behind it. Verify first, then trust the claim.
- Verify the JWT signature against the identity provider's published key (JWKS) before reading any group claim, and reject
alg:none. - Confirm the token's issuer and audience match your application so a token minted elsewhere cannot be replayed.
- Re-check group membership against the provider for sensitive admin actions rather than trusting a long-lived cached claim.
- Keep tokens short-lived and log privilege-sensitive actions so a forged group is detectable.