Directive-based authorization in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

What is the result of this GraphQL query with directive-based authorization?

Given this GraphQL schema snippet with a directive @auth(role: "ADMIN") on the secretData field, what will be the result of the query below if the user role is USER?

query {
  secretData
}

GraphQL

type Query {
  secretData: String @auth(role: "ADMIN")
}

A { "data": {} }

B { "data": { "secretData": null } }

C { "data": { "secretData": "Top secret info" } }

D { "errors": [{ "message": "Not authorized" }] }

💡 Hint

Think about what happens when a user without the required role tries to access a protected field.

The @auth directive restricts access to the secretData field to users with the ADMIN role. Since the user has the USER role, the server returns an authorization error.

🧠 Conceptual

intermediate

Which statement best describes directive-based authorization in GraphQL?

Choose the correct description of how directive-based authorization works in GraphQL schemas.

A Directives are only used for formatting query results, not for security.

B Directives replace the need for authentication by validating user identity.

C Directives are used to define access rules on schema fields that the server enforces during query execution.

D Directives automatically encrypt data fields before sending them to clients.

💡 Hint

Consider what role directives play in controlling access to data.

Directive-based authorization uses directives to specify access control rules on schema fields. The server checks these rules when resolving queries to allow or deny access.

📝 Syntax

advanced

Identify the syntax error in this directive definition

Which option shows the correct way to define a custom @auth directive that accepts a role argument of type String?

GraphQL

directive @auth(role: String) on FIELD_DEFINITION

A directive @auth(role: String) on FIELD_DEFINITION

B directive @auth(role String) on FIELD_DEFINITION

C directive @auth(role: "String") on FIELD_DEFINITION

D directive @auth(role: String!) on FIELD_DEFINITION

💡 Hint

Remember the syntax for defining arguments in directives.

The correct syntax uses a colon : to specify the argument type without quotes. Option A misses the colon, C incorrectly quotes the type, and D uses a non-null type which is allowed but not shown in the original.

❓ optimization

advanced

How to optimize directive-based authorization for multiple roles?

You want to allow access to a field for users with roles ADMIN or MODERATOR. Which directive usage is the most efficient and correct?

A @auth(roles: ["ADMIN", "MODERATOR"])

B @auth(role: ["ADMIN", "MODERATOR"])

C @auth(role: "ADMIN") @auth(role: "MODERATOR")

D @auth(role: "ADMIN,MODERATOR")

💡 Hint

Think about how to pass multiple values as an argument in GraphQL directives.

Passing an array of roles as role: ["ADMIN", "MODERATOR"] is the correct way to specify multiple allowed roles in one directive. Option B repeats the directive which is invalid, C uses a wrong argument name, and D passes a string instead of an array.

🔧 Debug

expert

Why does this directive-based authorization fail to block unauthorized access?

Given this schema snippet, unauthorized users can still access privateInfo. What is the likely cause?

directive @auth(role: String) on FIELD_DEFINITION

type Query {
  privateInfo: String @auth(role: "ADMIN")
}

A The directive is defined but not implemented in the server resolver logic.

B The directive argument should be <code>roles</code> instead of <code>role</code>.

C The directive must be applied on the <code>type Query</code> instead of the field.

D The directive syntax is invalid and causes the server to ignore it.

💡 Hint

Defining a directive in the schema is not enough to enforce authorization.

GraphQL directives require server-side implementation to enforce rules. Simply declaring the directive in the schema does not block access unless the server checks the directive during query execution.

Practice

1. What is the main purpose of using directive-based authorization in GraphQL?

easy

A. To control who can access certain data or operations

B. To speed up query execution

C. To format the output data

D. To create new database tables

Solution

1. Step 1: Understand directive-based authorization

   Directive-based authorization adds rules to GraphQL fields or types to restrict access based on user roles or permissions.

2. Step 2: Identify the main goal

   The main goal is to control access to data or operations, ensuring only authorized users can see or change certain information.

3. Final Answer:

   To control who can access certain data or operations -> Option A

4. Quick Check:

   Authorization controls access = B [OK]

Hint: Authorization directives control access permissions [OK]

Common Mistakes:

• Confusing authorization with performance optimization
• Thinking directives format data output
• Assuming directives create database structures

2. Which of the following is the correct syntax to apply a directive named @auth requiring a role ADMIN on a GraphQL field?

easy

A. type Query { secretData: String @auth(role: ADMIN) }

B. type Query { secretData: String @auth(role: "ADMIN") }

C. type Query { secretData: String @auth(role=ADMIN) }

D. type Query { secretData: String @auth[role=ADMIN] }

Solution

1. Step 1: Recall directive syntax in GraphQL

   Directives use parentheses with named arguments and string values in quotes, e.g., @directiveName(argName: "value").

2. Step 2: Match the correct syntax

   type Query { secretData: String @auth(role: "ADMIN") } correctly uses @auth(role: "ADMIN") with quotes around the string role value.

3. Final Answer:

   type Query { secretData: String @auth(role: "ADMIN") } -> Option B

4. Quick Check:

   Directive args use parentheses and quotes = D [OK]

Hint: Directives use parentheses and quoted strings for arguments [OK]

Common Mistakes:

• Using square brackets instead of parentheses
• Omitting quotes around string values
• Using equals sign without quotes

3. Given the schema snippet:

type Query {
  userProfile: User @auth(role: "USER")
}

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

What happens when a user with role USER queries userProfile { id email secretNote }?

medium

A. The query returns only id

B. The query returns all fields including secretNote

C. The query fails with an authorization error

D. The query returns id and email, but secretNote is blocked

Solution

1. Step 1: Analyze field-level directives

   The userProfile field requires role USER, so the user can access it. The secretNote field requires ADMIN role, which the user does not have.

2. Step 2: Determine accessible fields

   The user can see id and email but not secretNote because of the stricter ADMIN directive on that field.

3. Final Answer:

   The query returns id and email, but secretNote is blocked -> Option D

4. Quick Check:

   Field directives restrict access individually = C [OK]

Hint: Field directives override parent access; check each field's role [OK]

Common Mistakes:

• Assuming all fields inherit parent directive permissions
• Expecting full data without role ADMIN
• Thinking query fails instead of partial data

4. Consider this schema snippet:

type Query {
  adminData: String @auth(role: "ADMIN")
}

Which of the following fixes the error if the directive @auth is not recognized by the GraphQL server?

medium

A. Define the @auth directive in the schema with directive @auth(role: String) on FIELD_DEFINITION

B. Remove the @auth directive from the schema

C. Change @auth to @authorize without defining it

D. Rename the field adminData to adminInfo

Solution

1. Step 1: Understand directive registration

   GraphQL requires custom directives to be declared in the schema before use, specifying their name, arguments, and locations.

2. Step 2: Apply correct fix

   Define the @auth directive in the schema with directive @auth(role: String) on FIELD_DEFINITION correctly defines the @auth directive with a role argument and usage on field definitions, enabling the server to recognize it.

3. Final Answer:

   Define the @auth directive in the schema with directive @auth(role: String) on FIELD_DEFINITION -> Option A

4. Quick Check:

   Custom directives must be declared in schema = A [OK]

Hint: Declare custom directives in schema before use [OK]

Common Mistakes:

• Removing directives without replacing authorization
• Using undefined directive names
• Changing field names unrelated to directive errors

5. You want to restrict access so that only users with role EDITOR or ADMIN can update posts. Which directive usage correctly applies this logic on the updatePost mutation?

hard

A. type Mutation { updatePost(id: ID!, content: String!): Post @auth(role: "EDITOR") @auth(role: "ADMIN") }

B. type Mutation { updatePost(id: ID!, content: String!): Post @auth(roles: ["EDITOR", "ADMIN"]) }

C. type Mutation { updatePost(id: ID!, content: String!): Post @auth(role_in: ["EDITOR", "ADMIN"]) }

D. type Mutation { updatePost(id: ID!, content: String!): Post @auth(role: "EDITOR" OR "ADMIN") }

Solution

1. Step 1: Understand role list syntax in directives

   To allow multiple roles, the directive argument should accept a list (array) of roles, often named role_in or similar, depending on implementation.

2. Step 2: Evaluate options for correct syntax

   type Mutation { updatePost(id: ID!, content: String!): Post @auth(role_in: ["EDITOR", "ADMIN"]) } uses @auth(role_in: ["EDITOR", "ADMIN"]), which correctly passes an array of roles to check for authorization.

3. Final Answer:

   type Mutation { updatePost(id: ID!, content: String!): Post @auth(role_in: ["EDITOR", "ADMIN"]) } -> Option C

4. Quick Check:

   Use array argument for multiple roles = A [OK]

Hint: Use array argument to list multiple allowed roles [OK]

Common Mistakes:

• Stacking multiple @auth directives instead of one with list
• Using invalid OR syntax inside directive argument
• Using wrong argument name like roles instead of role_in