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.