Directive-based authorization in GraphQL - Step-by-Step Execution

Concept Flow - Directive-based authorization

Client sends GraphQL query

↓

GraphQL server parses query

↓

Server checks for authorization directives

↓

Evaluate directive conditions

↓

Allow field

↓

Return data

↓

Send response

The server reads the query, checks authorization directives on fields, allows or denies access accordingly, then returns data or errors.

Execution Sample

GraphQL

query {
  user {
    id
    email @auth(role: "ADMIN")
  }
}

A query requesting user id and email, where email requires ADMIN role authorization.

Execution Table

Step	Field	Directive Check	User Role	Authorization Result	Action
1	user	No directive	USER	Allowed	Resolve user data
2	user.id	No directive	USER	Allowed	Return id value
3	user.email	@auth(role: "ADMIN")	USER	Denied	Return error or null for email
4	Response	-	-	-	Send user id and error/null for email

💡 Authorization directive on email fails for USER role, so email is not returned.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
user	null	{id: 1, email: '[e-mail]'}	{id: 1, email: '[e-mail]'}	{id: 1, email: '[e-mail]'}	{id: 1, email: null}
user.id	null	1	1	1	1
user.email	null	[e-mail]	[e-mail]	denied	null

Key Moments - 2 Insights

Why is the email field not returned even though it exists in the data?

Because the email field has an @auth directive requiring ADMIN role, and the user role is USER, so authorization fails (see execution_table step 3).

What happens if a field has no authorization directive?

Fields without directives are allowed by default, so their data is returned normally (see execution_table steps 1 and 2).

Visual Quiz - 3 Questions

Look at the execution table, what is the authorization result for the user.id field at step 2?

A Allowed

B Denied

C Not checked

D Error

💡 Hint

Check the 'Authorization Result' column for step 2 in the execution_table.

At which step does the authorization directive cause a denial?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look for the step where 'Authorization Result' is 'Denied' in the execution_table.

If the user role was ADMIN instead of USER, how would the authorization result for user.email change?

A It would still be Denied

B It would be Allowed

C It would be Not checked

D It would cause an error

💡 Hint

Refer to the 'Directive Check' and 'User Role' columns in the execution_table step 3.

Concept Snapshot

Directive-based authorization in GraphQL:
- Use directives like @auth(role: "ADMIN") on fields
- Server checks user role against directive
- If authorized, field data is returned
- If denied, field returns error or null
- Fields without directives are allowed by default

Full Transcript

Directive-based authorization in GraphQL works by adding special instructions called directives to fields in a query. When a client sends a query, the server reads it and looks for these directives. For each field with a directive, the server checks if the user has the required role. If yes, the field's data is returned. If not, the field returns an error or null. Fields without directives are returned normally. For example, if a field requires ADMIN role but the user is USER, that field's data is not returned. This process ensures only authorized users see sensitive data.