How to check for custom OpenID claim in an IAM role's trust policy?

Question

I am authenticating users with auth0 to receive a id token containing the following claim

"http://myapp.com/scope": "write"

Using a Cognito identity pool with an OpenID authentication provider (namely, auth0), I am able to successfully get temporary credentials to access aws services. However, I want to restrict access to these services based on my custom claim above. I believe the proper way to do this is by editing the trust policy associated with my identity pool, but I am not sure how to add a condition to check for the above claim in my trust policy.

The current default trust policy is

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "us-east-2:078855cf-aa9b-400e-a762-dfcf27ec495c"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

How can I ensure that only users with the auth0 "write" scope have access to write to my s3 service?

UPDATE:

I was able to pass the original id_token to aws by avoiding the cognito identity pool. However, auth0 forces my custom claims to be namespaced with "http://mywebsite.com". This is a problem because IAM does not allow multiple colons in my condition. I need to add the condition

"ForAnyValue:StringLike": {
    "food-flick.auth0.com/:https://foodflick.com/scope": "write:rests"
 }

But IAM won't allow it and Auth0 forces me to namespace my claims. What can I do? I could store my scopes in a standard claim, but that would be misleading. Can I pass my access token instead of my id_token to IAM? If so, how would I change the trust policy to check for the appropriate aud value when given an array of values?

Answer 1

Federated claims are not propagated into the AWS session and are not accessible in the trust policy. Likely the path forward is to use RoleMappings to map your custom claim to a particular role. Unfortunately at this time, I believe there is an outstanding issue preventing rolemapping from working with OIDC. I will update this post if the issue is resolved.