@auth with groupsField and groupClaim not working in V2 transformer

[spc16670]

Before opening, please confirm:

• I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
• I have searched for duplicate or closed issues.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?

npm

If applicable, what version of Node.js are you using?

14

Amplify CLI Version

7.6.20

What operating system are you using?

Windows

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No manual changes made

Amplify Categories

auth, api

Amplify Commands

add

Describe the bug

I upgraded from GraphQL transformer version: 1 to 2, updated my schema, deployed the changes and I see getting awful lot of 'Unauthorized' responses completely breaking my app in many places.

This is my model (one of them):

type Client @model
  @auth(rules: [
    { allow: groups, groups: ["Root"] },
    { allow: groups, groups: ["Partner"], operations: [create] },
    { allow: groups, groupsField: "id", groupClaim: "client:owner" },
    { allow: groups, groupsField: "id", groupClaim: "client:custodian", operations: [read, update] },
    { allow: groups, groupsField: "id", groupClaim: "client:user", operations: [read] }
  ]) 
{
  id: ID! @primaryKey
  name: String!
  createdAt: AWSDateTime!
  updatedAt: AWSDateTime
}

I configure amplify to send ID token to the server

Amplify.configure({
  API: {
    graphql_headers: async () => {
      const session = await Auth.currentSession();
      const idToken = session.getIdToken();
      return {
        Authorization: idToken.getJwtToken()
      };
    }
  },
});

My token has:

client:custodian: "[\"GVP8919\"]"

There is the corresponding entry in the database with that ID.

And yet, the list operation does not return any results 😦

{"data":{"listClients":{"__typename":"ModelClientConnection","items":[],"nextToken":null}}}

I am using Cognito user pools for authentication.

Expected behavior

@auth with groupsField and groupClaim works the way it used to

Reproduction steps

1. Update to V2
2. Create a model as described below
3. Login as user with Cognito Id token with custom claim as shown above
4. Attempt a list on the model

GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line

Additional information

No response

[yuth]

@spc16670 Its hard to understand the problem without the records and schemas. Could you share GraphQL schemas with v1 and v2 which can be used to reproduce this issue. Please ensure there isn't any confidential info in the schema.

Also include a few mutation which can be used to create records in V1 and query to retrieve those in V2.

[spc16670]

My v1 version of the schema is not very different:

type Client @model 
  @auth(rules: [
    { allow: groups, groups: ["Root"] }
    { allow: groups, groups: ["Partner"], operations: [create] }
    { allow: groups, groupsField: "id", groupClaim: "client:owner" }
    { allow: groups, groupsField: "id", groupClaim: "client:custodian", operations: [read, update] }
    { allow: groups, groupsField: "id", groupClaim: "client:user", operations: [read] }
  ]) 
{
  id: ID!
  name: String!
  createdAt: AWSDateTime!
  updatedAt: AWSDateTime
}

I don't use any custom transformers - all stock amplify.

Is there any reason why the earlier schema and list operation done by a user with only client:custodian claim with a value of "[\"GVP8919\"]" should not work in v2 (given there is a record with id GVP8919 in the Client table)?

[yuth]

I am not sure. Could you also include the Mutations where I can insert record to client with GVP8919. Also include the list query used in both V1 and V2

[spc16670]

I used standard mutations as generated by amplify - same with list queries. I tried the list query in app sync console as well and it is giving the same results.

Here is the list query:

query MyQuery {
  listClients {
    items {
      createdAt
      id
      name
      updatedAt
    }
  }
}

[hanna-becker]

We have the same issue after upgrading to the new transformer.

Simplified model:

type Project
@model
@auth(rules: [
  { allow: owner },
  { allow: groups, groupsField: "id", operations: [read, update] }
])
{
  id: ID!
  name: String!
}

In the PreTokenGenerator's alter-claims.js function, after fetching the projects the user should have access to, we're adding their ids as groups:

  event.response = {
      claimsOverrideDetails: {
        groupOverrideDetails: {
          groupsToOverride: projectIDs
        }
      }
  };

I can see that the group got added correctly to the client's JWT token, when decoded:

"cognito:groups": [
    "e3673234-bc4b-4700-892c-fa282fbc1919"
]

However, the user gets unauthorized errors for querying that project.

This used to work previously.

Our current amplify-cli version is 7.6.21.

[alex-vladut]

I subscribe to this, I am also facing multiple issues in that area. Not sure what Amplify team's plans are and if they are going to tackle it. I added a PR a while back to fix some of these issues but it seems they are not accepting any PRs at the moment due to some internal refactoring I understand aws-amplify/amplify-cli#9535 (comment)

[endoodev1]

We are also having this problem as I have described in aws-amplify/amplify-cli#9466 here So I would also be more than happy to see a solution for this very soon!
Moreover I think this problem needs to be stated somewhere in the docs as a "known limitation" as long as this is not fixed. I think for most of the people running in this issue it is not very understandable.
As some other guys (thanks @n0rb) found out, the bug comes up because the authentication vtl rules for an "id" field are created in queries.ts by generateAuthOnModelQueryExpression method while the rules for the other "non id fields" were created by generateAuthFilter method. So you are seeing this issue as you are also using "groupsField: id".
Our model looks like this and has the same issue:

type Location @model 
@auth(rules: [ 
  { allow: groups, groups: ["Admin"], operations: [create, read, update, delete] } 
  { allow: groups, groupsField: "id", groupClaim: "la", operations: [read, update, delete] } 
]) {
  id: ID!
}

cc @danielleadams (I'm not sure you are the right contact person but you helped in aws-amplify/amplify-cli#9535)

[hanna-becker]

Thanks for this comment, @endoodev1. With this information I was able to create a workaround for our use case until this issue is properly fixed. I added a new "group" property to the Project table that I duplicate the id value into. (This requires the Create query followed by and Update query, as the id is autogenerated, thus unknown at the time of creation.) At least this way we can get all our app's collab features working again and unblock development.

type Project
@model
@auth(rules: [
  { allow: owner },
  { allow: groups, groupsField: "group", operations: [read, update] }
])
{
  id: ID!
  group: String! # duplication of id for @auth group claim
  name: String!
}

Not sure group needs to necessarily be a required field, like I implemented it.

[danielleadams]

@spc16670 Thanks for reporting this (and thanks all for the chiming in) - I know you've provided a lot of information here, but can you provide specific reproduction steps to investigate this? I tried the following:

1. Create api with transformer v1, the group ID is set as the record ID. example schema:

type Group @model @auth(rules: [
  { allow: owner, operations: [create, update, delete] }
  { allow: groups, groupsField: "id", operations: [read] }
]) {
  id: ID!
  name: String!
}

2. Create 2 users in cognito and add them to a group
3. Create records as user 1, set the record's group to the group's group name
4. Update API to use transformer v2 with the following schema:

type Group @model @auth(rules: [
  { allow: owner }
  { allow: groups, groupsField: "id", operations: [read] }
]) {
  id: ID!
  name: String!
}

5. amplify push
6. Query list as user 1, returns list as expected with the previously created record
7. Query list as user 2, returns list with user 1's previously created record as expected

I've also tried variations of this, and I'm not able to reproduce. What am I missing here?