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:
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:
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:And another one where all
@aws_auth
is replaced with@aws_cognito_user_pools
. The user is in theuser
group, so thecognito_groups: ["admin"]
should deny access.When I send this query to the API where Cognito is the only auth provider:
only the query_scalar is denied:
But when I send the same query to the API with 2 authorization modes, all fields are denied:
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