ScopeAuth Plugin - Prevent User From Accessing Other Group's Data

[arimgibson]

Hi all! I'm currently working on an application that consists of users belonging organizations. While there are different roles inside the organization, no one should be able to access data from other organizations.

My original thought, which probably works, is to have the following authScope on each object:

builder.prismaObject('User', {
  runScopesOnType: true,
  authScopes: (user, context) => {
    if (context.user.org.id !== user.organization_id) return false;
    ...
  },
})

However, this is a little repetitive and could be error prone to implement and maintain on every single object. Is there an easier way to do this on a global scope?

Another idea worth mentioning would be to add the user's organization ID to each query's where field, but again, that's quite repetitive. And, because Prisma would return just an empty object when the user's organization doesn't match the organization of the data they're requesting, we wouldn't know if the data simply didn't exist or if the user was unauthorized.

Thanks!

[hayes]

Generally having auth enforced as part of your queries so content the user isn't authorized for is never loaded is ideal (adding conditions to your where clause). Pothos doesn't really provide anything that helps with this though.

There isn't a good way to global define and enforce these rules across multiple objects, because Pothos doesn't really understand the relations between the different objects in a way that would allow knowing if a particular relation denotes ownership/access.

What you can do share/simplify how the auth scope for organizations is defined:

You can create a scope like accessOrganization: string, that does something like

authScopes: (ctx) => ({
  accessOrganization: (id) => ctx.user.organizationId === id,
})

Then on your objects:

builder.prismaObject('User', {
  runScopesOnType: true,
  authScopes: (user) => ({ accessOrganization: user.organizationId }),
 ...
})

Not sure if this helps

[orinoco]

It seems the resolver runs before the authScopes are checked? Which leads me to believe this is not the way to do this?

[arimgibson]

@hayes can fact check me here but I believe the auth scopes determine what data should be returned after the resolver runs like you found -- the correct approach would be running authScopes as a function inside your resolvers

See #905

{
  resolve: async (root, args, ctx) => {
    const user = await loadUser(args)
    await builder.runAuthScopes({
      developer: true,
      teacher: parseInt(ctx, args.input.id.id, 10),
      admin: user.organizarion_id
    })
   return deleteUser(args)
  }
}

[hayes]

Yes, this is expected.

How would this work? The auth check on the user requires the users ID, and reads it of the user object, which obviously requires the previous resolver to run and return the user object first.

If you want to prevent the mutation from running, you need to define an auth check on the mutation field or type.

[hayes]

@arimgibson's solution is the way to go if you need to load the user first.

If the relevant IDs are in context or args, you can just define scopes directly on the field.

To clarify @arimgibson description through:

Checks aren't run after resolvers, they are run before resolvers, it's just a matter of which resolvers.

When the scopes are defined on a field, the checks are enforced before that fields resolver runs. When they are defined on a type, they are added to each of that types fields

[orinoco]

Got it, thanks!