Doubt: Authorization constraints in resolvers or shield permissions

Question about GraphQL concepts

1. Is it right to assume that I only need to care about auth and permissions on scalar fields only? By this, I mean:

type Customer {
  id: ID!
  name: String!
  sensitiveData: UserSensitiveData!
  ...
}
type Customer SensitiveData {
  id: ID!
  customer : Customer !
  data1: String!  # authorization verification from DB here in resolvers
  data2: ... # authorization verification from DB here in resolvers
}
Rules:
export const permissions = shield({
  Customer : allow,
  CustomerSensitiveData: isUserCustomer
})

EDIT: I now have a feeling/understanding that this could leak fields like id in related type for an authenticated, but unauthorized access. For instance, id in Product is public, so purchasedProducts in type Customer, if not verified for authorization, could leak that id (and other product identifier) to an authenticated customer access trying to access other customer’s resources. So, authorization should be on the edges, not on the nodes.

1. How do I ensure that an authorized user is deleting say, wishlisht of its own? (Right now, I am using $exists from prisma client in resolvers to check if the user has that item, then only allow deletion). Should this constraint be somehow placed in the shield rule?

Question about GraphQL Shield

1. What are fragments in shield? Are they the one to use when I have to constraint some fields of a type to be public, and some to be authorized (but these could be achieved with field level rule defs, couldnt they?)

• I have checked other questions and found none that matches mine.

[maticzav]

Hey 👋,

I am not sure I understand your question entirely. In particular, what are you referring to with AuthZ? Maybe the example below could give you some ideas on how to tackle the issue.

type Query {
  viewer: User
}

type User {
    id: ID!
    email: String!
    tickets: [Ticket!]!
}

type Ticket {
  id: ID!
  event: PublicEvent!
  owner: User!
  isValidated: Boolean!
  isExpired: Boolean!
}

const isUserTicketOwner = rule({
  cache: 'strict',
  fragment: 'fragment TicketId on Ticket { id } ',
})(async ({ id }, args, ctx: Context) => {
  try {
    const userId = getUserId(ctx)

    return ctx.prisma.exists.Ticket({
      id: id,
      owner: { id: userId },
    })
  } catch (err) {
    return false
  }
})

export const permissions = shield(
  {
    Query: {
      viewer: allow,
    },
    User: isUserAuthenticated,
    Ticket: or(isUserAdministrator, isUserModerator, isUserTicketOwner),
  },
  {
    debug: process.env.NODE_ENV !== 'production',
    fallbackError: 'To pa ne gre...',
    fallbackRule: deny,
  },
)

That’s how I would approach writing permissions. As you can see, User only checks whether user is indeed authenticated, while Ticket also verifies that current user owns it.

I hope this helps you solve your problem 🙂

[maticzav]

@devautor no worries, I could have guessed that! 🙈 What you could do is set up an interface type and somehow validate the ownership that way, however, I am not entirely sure how would that work.