Cognito AssumeRole Audience Mismatch Tracker

The Incident (What does the error mean?)

You hit this raw error from STS:

An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation:
  Token is not valid: Token audience is invalid

Or in CloudTrail:

{
  "eventName": "AssumeRoleWithWebIdentity",
  "errorCode": "InvalidIdentityToken",
  "errorMessage": "Token is not valid: Token audience is invalid"
}

Immediate consequence: Every federated authentication attempt fails. Your mobile app, SPA, or backend service cannot obtain temporary AWS credentials. If this is a user-facing login flow backed by Cognito Identity Pools, your entire auth pipeline is down.

STS validates the JWT's aud claim against the StringEquals condition in the trust policy before it even evaluates the role's permission policies. There is no partial success here — it's a hard reject at the federation handshake layer.

The Attack Vector / Blast Radius

This is not just a misconfiguration inconvenience — the audience condition is a security boundary.

Why the aud check exists: Without a strict audience match, any valid JWT issued by your Cognito User Pool — regardless of which App Client it was issued for — could be used to assume the role. An attacker who obtains a JWT from a low-privilege App Client (e.g., a public-facing web client with minimal scopes) could attempt to assume a role intended only for a trusted backend service client.

Blast radius if you "fix" this by removing the aud condition entirely:

• Any token from any App Client in your User Pool can assume the role.
• If your User Pool has a public self-registration flow, an attacker registers, gets a JWT, and calls AssumeRoleWithWebIdentity directly against your backend role.
• Combined with an overly permissive role policy, this is a full privilege escalation path from anonymous user to AWS API access.

The correct fix is not to remove the condition — it's to set the right value.

Prevention in CI/CD

1. Checkov — catch placeholder/mismatched audience at plan time:

Write a custom Checkov check or use the built-in CKV_AWS_62 (ensure Cognito roles have constrained trust). Add to your pipeline:

# .github/workflows/iac-scan.yml
- name: Checkov IaC Scan
  uses: bridgecrewio/checkov-action@master
  with:
    directory: ./terraform
    check: CKV_AWS_62,CKV_AWS_156
    soft_fail: false

2. OPA/Conftest — enforce that aud condition is never a wildcard or empty:

# policies/cognito_trust.rego
package aws.iam.trust

deny[msg] {
  stmt := input.Statement[_]
  stmt.Action == "sts:AssumeRoleWithWebIdentity"
  not stmt.Condition.StringEquals["cognito-identity.amazonaws.com:aud"]
  msg := "AssumeRoleWithWebIdentity trust policy missing cognito:aud StringEquals condition"
}

deny[msg] {
  stmt := input.Statement[_]
  aud := stmt.Condition.StringEquals["cognito-identity.amazonaws.com:aud"]
  contains(aud, "PLACEHOLDER")
  msg := sprintf("Cognito aud condition contains unreplaced placeholder: %v", [aud])
}

3. Terraform validation block — fail fast before apply:

variable "cognito_identity_pool_id" {
  type        = string
  description = "Cognito Identity Pool ID for IAM trust policy audience"

  validation {
    condition     = can(regex("^[a-z]{2}-[a-z]+-[0-9]:[a-f0-9-]{36}$", var.cognito_identity_pool_id))
    error_message = "cognito_identity_pool_id must match format: us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  }
}

4. CloudTrail Alarm — alert on repeated InvalidIdentityToken in production:

aws cloudwatch put-metric-filter \
  --log-group-name CloudTrail/DefaultLogGroup \
  --filter-name CognitoAudienceMismatch \
  --filter-pattern '{ ($.eventName = "AssumeRoleWithWebIdentity") && ($.errorCode = "InvalidIdentityToken") }' \
  --metric-transformations metricName=InvalidIdentityTokenCount,metricNamespace=Security/STS,metricValue=1

This catches both misconfiguration regressions after deploys and active token-probing attempts by external actors.