@aws_auth works differently than @aws_cognito_user_pools

[sashee]

The @aws_auth is effective only when Cognito is the only auth provider and @aws_cognito_user_pools is used when there are other ones. My understanding was that they work identically, the only difference is which one to use based on the authorizer config.

But it seems like the @aws_auth does not take directives on nested fields into account. I made a test to see how the two scenarios work side-by-side:

type Inner {
	inner_scalar: String
		@aws_auth(cognito_groups: ["admin"])
}

type Outer {
	scalar: String
		@aws_auth(cognito_groups: ["admin"])
	inner: Inner
		@aws_auth(cognito_groups: ["admin"])
}

type Query {
	query_scalar: String
		@aws_auth(cognito_groups: ["admin"])
	outer: Outer
		@aws_auth
}

And another one where all @aws_auth is replaced with @aws_cognito_user_pools. The user is in the user group, so the cognito_groups: ["admin"] should deny access.

When I send this query to the API where Cognito is the only auth provider:

query MyQuery {
  query_scalar
  outer {
    scalar
    inner {
      inner_scalar
    }
  }
}

only the query_scalar is denied:

{
  "data": {
    "query_scalar": null,
    "outer": {
      "scalar": "outer_scalar",
      "inner": {
        "inner_scalar": "inner_scalar"
      }
    }
  },
....
}

But when I send the same query to the API with 2 authorization modes, all fields are denied:

{
  "data": {
    "query_scalar": null,
    "outer": {
      "scalar": null,
      "inner": null
    }
  },
...
}

The @aws_auth should deny the fields the same as the directives in the other API.

An example project that you can deploy can be found here: https://github.com/sashee/appsync-auth-directives-test/tree/0b4eeb7ef716a1a8269926555561a8fd38492bd9