Field-level permissions in GraphQL - Mini Project: Build & Apply

Field-level Permissions in GraphQL

📖 Scenario: You are building a GraphQL API for a company that wants to control which users can see certain fields in the data. For example, only admins can see the salary field of employees, while all users can see the name and position fields.

🎯 Goal: Create a GraphQL schema with an Employee type that has fields name, position, and salary. Implement field-level permissions so that the salary field is only accessible to users with the role ADMIN.

📋 What You'll Learn

Define an Employee type with fields name, position, and salary

Create a query employees that returns a list of Employee

Add a context variable userRole to simulate the current user's role

Implement resolver logic to restrict access to the salary field based on userRole

Ensure users without ADMIN role receive null for the salary field

💡 Why This Matters

🌍 Real World

Field-level permissions are essential in real-world APIs to protect sensitive data and comply with privacy rules.

💼 Career

Understanding how to implement field-level permissions in GraphQL is valuable for backend developers building secure APIs.

1

Define the Employee type and Query

Create a GraphQL schema with an Employee type that has fields name (String), position (String), and salary (Float). Also define a Query type with a field employees that returns a list of Employee.

GraphQL

# Define the Employee type and Query type in SDL
# Your code here

Hint

Use GraphQL SDL syntax to define types and fields exactly as specified.

2

Add userRole to context and sample data

Add a variable called userRole in the context to simulate the current user's role. Also create a sample list of employees with exact entries: { name: "Alice", position: "Developer", salary: 70000 } and { name: "Bob", position: "Manager", salary: 90000 }.

GraphQL

type Employee {
  name: String
  position: String
  salary: Float
}

type Query {
  employees: [Employee]
}

const userRole = "USER";
const employees = [
  { name: "Alice", position: "Developer", salary: 70000 },
  { name: "Bob", position: "Manager", salary: 90000 }
];
# Your code here

Hint

Define userRole as a string and employees as an array of objects with exact properties and values.

3

Implement resolver for employees query

Write a resolver function for the employees query that returns the employees list. Use the userRole variable from context to control access to the salary field by returning null for salary if userRole is not ADMIN. Use a field resolver for salary inside the Employee type.

GraphQL

type Employee {
  name: String
  position: String
  salary: Float
}

type Query {
  employees: [Employee]
}

const userRole = "USER";
const employees = [
  { name: "Alice", position: "Developer", salary: 70000 },
  { name: "Bob", position: "Manager", salary: 90000 }
];

const resolvers = {
  Query: {
    employees: () => employees
  },
  Employee: {
    salary: (employee) => {
      // Your code here
    }
  }
};

Hint

Use a resolver for salary that checks userRole and returns null if not ADMIN.

4

Complete schema and export

Add the final code to create the GraphQL schema using makeExecutableSchema from @graphql-tools/schema with the defined typeDefs and resolvers. Export the schema as schema.

GraphQL

type Employee {
  name: String
  position: String
  salary: Float
}

type Query {
  employees: [Employee]
}

const userRole = "USER";
const employees = [
  { name: "Alice", position: "Developer", salary: 70000 },
  { name: "Bob", position: "Manager", salary: 90000 }
];

const resolvers = {
  Query: {
    employees: () => employees
  },
  Employee: {
    salary: (employee) => {
      if (userRole === "ADMIN") {
        return employee.salary;
      } else {
        return null;
      }
    }
  }
};

import { makeExecutableSchema } from '@graphql-tools/schema';

// Your code here

Hint

Use makeExecutableSchema with typeDefs and resolvers and export the schema.

Practice

1. What is the main purpose of field-level permissions in GraphQL?

easy

A. To cache query results

B. To control access to individual data fields

C. To define the schema structure

D. To speed up query execution

Solution

1. Step 1: Understand the concept of field-level permissions

   Field-level permissions restrict who can see or edit specific fields in data, protecting sensitive information.

2. Step 2: Identify the main purpose

   The main goal is to control access to individual data fields, not to speed up queries or define schema structure.

3. Final Answer:

   To control access to individual data fields -> Option B

4. Quick Check:

   Field-level permissions = control access [OK]

Hint: Focus on access control for each field, not overall schema [OK]

Common Mistakes:

• Confusing permissions with schema design
• Thinking it speeds up queries
• Assuming it caches data

2. Which of the following is the correct way to apply a field-level permission directive in a GraphQL schema?

easy

A. type User { email: String @auth(role: "admin") }

B. type User { email: String auth(role: "admin") }

C. type User { email: String @auth[role="admin"] }

D. type User { email: String #auth(role: "admin") }

Solution

1. Step 1: Recall GraphQL directive syntax

   Directives use the @directiveName(arguments) format placed after the field type.

2. Step 2: Match the correct syntax

   type User { email: String @auth(role: "admin") } uses @auth(role: "admin") correctly. Options A, B, and D have syntax errors or wrong symbols.

3. Final Answer:

   type User { email: String @auth(role: "admin") } -> Option A

4. Quick Check:

   Directive syntax = @name(args) [OK]

Hint: Remember directives start with @ and use parentheses [OK]

Common Mistakes:

• Omitting the @ symbol
• Using brackets [] instead of parentheses ()
• Commenting out the directive

3. Given this GraphQL query and schema with field-level permissions:

type User { id: ID! name: String email: String @auth(role: "admin") }

If a user with role "user" runs:

{ user { id name email } }

What will be the result?

medium

A. { "data": { "user": { "id": "1", "name": "Alice", "email": "[e-mail]" } } }

B. { "data": { "user": { "id": "1", "name": "Alice", "email": null } } }

C. Error: Unauthorized to access field 'email'

D. { "data": { "user": { "id": "1", "name": "Alice" } } }

Solution

1. Step 1: Understand the permission on the email field

   The @auth(role: "admin") directive restricts email access to admin role only.

2. Step 2: Predict query result for a user role

   The user role is not admin, so email field is omitted from the response, not returned as null or error.

3. Final Answer:

   { "data": { "user": { "id": "1", "name": "Alice" } } } -> Option D

4. Quick Check:

   Unauthorized fields are omitted, not null or error [OK]

Hint: Unauthorized fields are hidden, not null or error [OK]

Common Mistakes:

• Expecting null instead of omitted field
• Expecting an error response
• Assuming all fields return regardless of role

4. You wrote this schema snippet:

type User { id: ID! name: String email: String @auth(role: admin) }

Why does this cause an error when applying field-level permissions?

medium

A. The role value admin should be a string in quotes

B. The @auth directive is not allowed on fields

C. ID! type cannot have directives

D. The email field must be nullable to use permissions

Solution

1. Step 1: Check the directive argument syntax

   Directive arguments must be valid GraphQL values; strings require quotes.

2. Step 2: Identify the error in role argument

   The role value admin is unquoted, causing a syntax error. It should be "admin".

3. Final Answer:

   The role value admin should be a string in quotes -> Option A

4. Quick Check:

   Directive args strings need quotes [OK]

Hint: Always put string arguments in quotes inside directives [OK]

Common Mistakes:

• Forgetting quotes around string arguments
• Thinking directives can't be on fields
• Assuming non-null types disallow directives

5. You want to allow users to see their own email field but only admins to see others' emails. Which field-level permission setup achieves this?

hard

A. Use @auth(role: "admin") on email field only

B. Make email field public and filter in resolver

C. Use a custom directive checking if user is owner or admin

D. Remove email field from schema and add a separate query

Solution

1. Step 1: Analyze the requirement

   Users can see their own email; admins can see all emails. This needs conditional logic.

2. Step 2: Evaluate options for conditional access

   Use a custom directive checking if user is owner or admin uses a custom directive to check ownership or admin role, fitting the requirement precisely.

3. Step 3: Why other options fail

   Use @auth(role: "admin") on email field only restricts email only to admins, blocking users from their own email. Make email field public and filter in resolver exposes email publicly, unsafe. Remove email field from schema and add a separate query complicates schema unnecessarily.

4. Final Answer:

   Use a custom directive checking if user is owner or admin -> Option C

5. Quick Check:

   Conditional access needs custom logic [OK]

Hint: Use custom directives for complex permission logic [OK]

Common Mistakes:

• Using simple role checks only
• Exposing sensitive fields publicly
• Overcomplicating schema with extra queries