Dynamic, row-scoped authorization (e.g. “member of club”) does not compose with generated model queries + selection sets

[mgreiner79]

Summary

I’m building an app with club-scoped data using AWS Amplify Gen 2 Data.
A common access rule is:

“A user may read data for a given clubId only if they are a member of that club.”

Today, this rule cannot be expressed in model authorization, and solving it via custom queries or resolvers breaks important features like frontend-controlled selection sets, filters, and reuse of generated model APIs.

⸻

Minimal example scenario

Models

User
- id
- sub

Club
- id
- name

ClubMember   // join table
- id
- clubId
- userId
- role
- status

Desired behavior

1. A user who is a member of a club should be able to:

   • list all members of that club
   • fetch nested data (e.g. member → user display name)

2. A user who is not a member of that club should receive Unauthorized.

3. The frontend should be able to:

   • use generated model queries (or equivalent)
   • control selection sets for nested objects
   • avoid N+1 queries

⸻

What works today

Case 1: “My memberships”

Using allow.ownerDefinedIn(...) works well for:

listClubMembersByOwner(...)

This supports:

• generated model queries
• frontend selectionSet
• no custom resolvers

⸻

What does NOT work

Case 2: “List members of a club I belong to”

This rule is dynamic:

allow if a row exists in ClubMember for (clubId, user)

There is currently no way to express this as:

allow.if( isMemberOfClub(ctx.identity, ctx.args.clubId) )

⸻

Attempted solutions & issues

1. Custom query (Lambda or AppSync JS resolver)
✔ Can enforce membership
❌ Cannot use generated client.models.* queries
❌ Cannot pass frontend selectionSet via client.queries.*
❌ Requires duplicating shapes (custom types, mapping, nested selection logic)

2. Lambda authorizer
✔ Can enforce access globally
❌ Replaces (rather than composes with) allow.owner, allow.groups
❌ Forces re-implementation of existing auth semantics

3. Frontend N+1 queries
❌ Inefficient
❌ Complex
❌ Defeats GraphQL’s purpose

⸻

Core problem

There is no composable way to say:

“Run the existing model authorization AND also check this custom condition.”

What’s missing is a concept similar to middleware / policy hooks that:

• run before resolvers
• have access to args (clubId)
• can perform a lookup
• do not replace existing allow.owner, allow.groups, etc.

⸻

Desired capability (conceptual)

Something like:

allow.custom((ctx) => {
  return isMemberOfClub(ctx.identity.sub, ctx.args.clubId)
})

Where:

• This check runs in addition to model auth
• Generated resolvers remain usable
• Frontend keeps selection sets, filters, pagination
• No need to re-implement existing queries

⸻

Why this matters

This pattern appears in many real apps:

• teams / organizations
• projects
• workspaces
• classrooms
• clubs

Currently, developers must choose between:

• strong authorization or
• good GraphQL ergonomics

⸻

Questions for the Amplify team

1. Is there a recommended pattern for dynamic, relationship-based authorization that preserves generated model queries?
2. Are there plans to support composable authorization hooks (policy/middleware-style)?
3. Is the lack of selectionSet support in client.queries.* intentional or a current limitation?

⸻

Closing

I really like Amplify Gen 2’s direction — especially the data modeling and generated APIs.
This gap is the one place where I consistently feel forced to “drop down a level” and lose the benefits of the system.

Happy to provide a runnable repro if useful.

[mgreiner79]

Note: This feature request would solve the core problem:
#457

In my app I use custom Lambdas for any operation that requires a dynamic authorization check (e.g. “is the caller a member of this club?”). That approach works fine as long as the client only needs flat fields.

However, it breaks down when the client needs nested/related data (e.g. ClubMember -> Club or ClubMember -> User). The reason is that custom operations accessed via client.queries.* currently don’t support passing a selectionSet (and model-style filters), so the client can’t request nested objects in the same way it can for client.models.*.

Nested data is especially important for many-to-many relationships like Club, User, ClubMember.

Without selectionSet support on custom queries, the remaining options are all undesirable:

1. Denormalize the needed fields onto the join model and maintain them (which requires additional sync logic whenever the source changes).
2. N+1 requests from the frontend (list memberships, then fetch each related Club / User in a loop).
3. Custom response types that duplicate the nested structure (leading to schema/type/mapper duplication and higher maintenance cost).

Having selectionSet and model-style filtering available for client.queries.* would enable custom auth checks while preserving the same ergonomics and efficiency as generated model queries.

[adrianjoshua-strutt]

Hi @mgreiner79,

Thank you for this feature request! We will review it with the team and get back to you once we have an update.

[chrisl777]

This issue is one that we're facing as well.

Arrays Approach

One approach we've considered is having various arrays for userIds (Cognito subs) consisting of lists of ownerIds, editorIds, viewerIds. And then a GroupGrant or UserGrant table that records if a group/user has access to a resource as a the "source of truth" for keeping the arrays updated.

The AppSync docs allude, rather cryptically, that “authorization metadata” must be stored for each row in a table, in order to figure out how to resolve authorization: https://docs.aws.amazon.com/appsync/latest/devguide/security-authorization-use-cases.html

But how do to implement a standard Access Control Matrix in practice with Amplify Gen 2 is a bit of a mystery.

For example, consider the case where you have a "Google Drive" like folder system, where users could have owner, editor, viewer access to a folder or document, and a sub-folder or document could override the parent auth rules (i.e. a user invited to a document within a folder that has different permissions than the parent).

Folder: a.model({
    contentType: a.string(),
    description: a.string(),
    documents: a.hasMany("Document", "folderId"),
    name: a.string().required(),
    organization: a.belongsTo("Organization", "organizationId"),
    organizationId: a.id().required(),
    parentId: a.id(),

    // Access control via user ID arrays (Cognito subs)
    // SECURITY: Only ownerIds has field-level auth to prevent editor privilege escalation
    ownerIds: a.id().array().authorization(allow => [
      allow.ownersDefinedIn("ownerIds")
    ]),
    editorIds: a.id().array(),
    viewerIds: a.id().array(),
  })
    .disableOperations(["subscriptions"])
    .secondaryIndexes((index) => [
      index("parentId").name("byParent").queryField("listFoldersByParent"),
      index("organizationId").name("byOrganization").queryField("listFoldersByOrganization")
    ])
    .authorization((allow) => [
      allow.custom().to(["create"]),
      // Resource-level permissions
      allow.ownersDefinedIn("ownerIds"),
      allow.ownersDefinedIn("editorIds").to(["read", "update"]),
      allow.ownersDefinedIn("viewerIds").to(["read"]),
      allow.group("Admin")
    ]),

GroupGrant: a.model({
    groupId: a.id().required(),
    group: a.belongsTo("Group", "groupId"),
    resourceType: a.ref("ResourceType").required(),  // Document|Folder|Event
    resourceId: a.id().required(),
    accessLevel: a.ref("AccessLevel").required(),    // Owner|Editor|Viewer|Commenter
    organizationId: a.id().required(),
    organization: a.belongsTo("Organization", "organizationId"),
    
    // Grant type - Direct or Inherited from parent folder
    grantType: a.ref("GrantType").required(),
    
    // Audit trail
    grantedBy: a.id(), // userId who granted access
    
    // Inheritance tracking - null for direct grants, parent resourceId for inherited
    inheritedFrom: a.id(),
  })
    .secondaryIndexes((index) => [
      index("groupId").name("byGroup").queryField("listGroupGrantsByGroup"),
      index("resourceId").name("byResource").queryField("listGroupGrantsByResource"),
    ])
    .authorization((allow) => [
      // SECURITY: No direct create - must use shareResource mutation that validates ownership
      // Org members can read grants for "who has access" UI
      allow.groupDefinedIn("organizationId").to(["read"]),
      allow.group("Admin"),
    ]),

UserGrant: a.model({
    organizationUserId: a.id().required(),
    organizationUser: a.belongsTo("OrganizationUser", "organizationUserId"),
    
    // Cognito user ID - needed for ownerDefinedIn authorization
    userId: a.id().required(),
    
    resourceType: a.ref("ResourceType").required(),  // Document|Folder|Event
    resourceId: a.id().required(),
    accessLevel: a.ref("AccessLevel").required(),    // Owner|Editor|Viewer|Commenter
    organizationId: a.id().required(),
    organization: a.belongsTo("Organization", "organizationId"),
    
    // Grant type - Direct or Inherited from parent folder
    grantType: a.ref("GrantType").required(),
    
    // Audit trail
    grantedBy: a.id(), // userId who granted access
    
    // Inheritance tracking - null for direct grants, parent resourceId for inherited
    inheritedFrom: a.id(),
  })
    .disableOperations(["subscriptions"])
    .secondaryIndexes((index) => [
      index("organizationUserId").name("byOrganizationUser").queryField("listUserGrantsByOrganizationUser"),
      index("resourceId").name("byResource").queryField("listUserGrantsByResource"),
      index("userId").name("byUser").queryField("listUserGrantsByUser"),
    ])
    .authorization((allow) => [
      // Users can read and delete their own grants (remove their own access)
      allow.ownerDefinedIn("userId").to(["read", "delete"]),
      // SECURITY: No direct create - must use shareResource mutation that validates ownership
      // Org members can read grants for "who has access" UI
      allow.groupDefinedIn("organizationId").to(["read"]),
      allow.group("Admin"),
    ]), 

Note in this case, we still need a custom authorizer to protect the "create" case to see if a user can create a row, and also a custom mutation to carry out the create operation. In some cases we need to add a user to a Cognito group named for their organizationId for when all users in an org can read data. For adding or removing members to a group, we would need several custom mutations.

The difficulty with this "arrays approach" is that we need these accounting tables (GroupGrant/UserGrant), plus functions that stream from the tables, the custom authorizer, and other custom queries/mutations for cases the auth rules do not handle, as well as management of the Cognito organizationId group. It makes for a very de-centralized and difficult developer experience.

It would be far easier if we could encapsulate all rules within the authorization section for a model. An even easier approach would be if we could create an ACL table in the schema that would translate that behind the scenes to the generated resolvers.

Speaking of the resolvers, there seems to be little in Gen 2 docs about creating custom JS resolvers that override the generated resolvers. Which seems like it would be one way to handle this thread of inquiry, but it's not apparent how to implement such an approach.

[pranavosu]

@chrisl777 yeah, you're hitting the same core issue that @mgreiner79 described and the arrays approach (ownerIds, editorIds, viewerIds) technically works but creates a lot of complexity, especially with inheritance patterns like your folder/document example.

regarding custom JS resolvers to override generated resolvers, it's unfortunately that's not currently supported in Gen 2 in a way that would allow this. The documentation focuses on creating new custom queries/mutations, but there's no way to override the auto-generated resolvers for model operations (like listFolders, getFolder etc.). This was possible in Gen 1 CLI by placing resolver templates in specific directories, but that capability doesn't exist yet in Gen 2.

None of the available workarounds are great but this is still on our radar and we will work through making this a better experience.

Thanks for the feedback!