[aws-cdk/appsync] - aws_auth directive ignored

[tombuckley91]

type Query {
  getCustomers: [Customer] 
  @aws_auth(cognito_groups: ["Admins"])
  getCustomer(id: String): Customer
}

It would be expected that the above code would restrict the getCustomers query to users who exist in the Admins group. This is an example of the starter code made available on the AppSync CDK page.

Reproduction Steps

Copy the demo code from AppSync CDK, add the above directive to the included graphql.schema, deploy your changes, make a query from a user that is not the specified group, expect to have information returned.

Error Log

Environment

• CLI Version : 1.47.1
• Framework Version:
• Node.js Version: 12.18.2
• OS : Mac OSX
• Language (Version): TypeScript (3.7.2)

Other

---

This is 🐛 Bug Report

[BryanPan342]

Hi Tom thanks for submitting an issue!

I reproduced what were showing me and I got mine to work by making the IAM Role policy for the groups Admins to be the admin. Can you clarify more steps to where your bug is? I'm guessing its permissions for the group.

[tombuckley91]

I reproduced what were showing me and I got mine to work by making the IAM Role policy for the groups Admins to be the admin. Can you clarify more steps to where your bug is? I'm guessing its permissions for the group.

Thank you for getting back to me @BryanPan342, I really appreciate it.

I'm not sure I fully understand, I created a group titled "Admins", to match what I specified in my schema, a user not in that group could still query data that was seemingly restricted from doing that (this is my bug). If I understand what you're saying correctly, you have created a new role that grants admin, and attached this to the "Admins" group, at which point you have requested some data and been given it, have you tried requesting from a user who is not in that group?

Thanks Bryan.

[BryanPan342]

Hm this is interesting.

So the policy statement should look something like this.

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
            "appsync:GraphQL"
         ],
         "Resource": [
            "arn:aws:appsync:[REGION]:[ACCOUNT_ID]:apis/[GRAPHQL_ID]/types/Mutation/fields/doMutation"
         ]
      }
   ]
}

where the resource section are the ARNs for the resources you want to allow access to for the policy you are creating. Something to note as well is if you are doing a Mutation, then make sure to also give access to the types in the schema directive:

type superSecret @aws_auth(cognito_groups: ["Admins"]) {
...
}

type Mutation {
  addSuperSecret (...): ...
  @aws_auth(cognito_groups: ["Admins"])
}

I know this works for IAM so assuming its the same use case for auth.

I'm looking into that condition you just said and will respond by tomorrow. If you need an Admins for backend tasks I suggest using IAM.

Also have you looked at this part of the documentation?

You can’t use the @aws_auth directive along with additional authorization modes. @aws_auth works only in the context of AMAZON_COGNITO_USER_POOLS authorization with no additional authorization modes. However, you can use the @aws_cognito_user_pools directive in place of the @aws_auth directive, using the same arguments. The main difference between the two is that you can specify @aws_cognito_user_pools on any field and object type definitions.

[BryanPan342]

From what I can see right now, I think this is more of a documentation problem than a bug so changing the label for now.

[tombuckley91]

Thanks for your investigation @BryanPan342 , did you come to a conclusion? Is the outcome that aws_auth is not supported by schemas deployed via CDK?

[BryanPan342]

@aws_auth is supported by cdk. However, something to note and follow from the appsync documentation is that @aws_auth only works for cognito if it's the ONLY form of authorization.

If you use additional authorization then you must use the @aws_cognito_user_pool directive. Additionally, there is was an issue before that created an apiKey if additionalAuthorization was not configured (#9054) that was fixed thanks to @warrify

I think what might have happened @tombuckley91 was that the bug from the apiKey was adding an additional configuration that made the @aws_auth directive unusable. Now that it's fixed though, as long as you only have a single configuration for authorization, @aws_auth should work (from my tests I have gotten it to work).

Rule of thumb:

• If only one authorization configuration, use @aws_auth
• If using multiple configurations, use @aws_cognito_user_pool

@aws_auth and @aws_cognito_user_pool are specific to ONE and MULTIPLE configurations respectively. You cant use @aws_auth for multiple configurations and you cant use @aws_cognito_user_pool for one configuration.

[BryanPan342]

I'm closing this issue for now but if there is something I missed, please reopen it or continue adding to the discussion.