GraphQL execution should begin after authentication middleware confirms the user’s identity and passes that information to the GraphQL layer. But after that, you still need to determine if the authenticated user is allowed to view the data provided by the specific fields that were included in the request.

It’s simple to use any Express middleware in conjunction with graphql-http. In a REST API, authentication is often handled with a header, that contains an auth token which proves what user is making this request. Express middleware processes these headers and puts authentication data on the Express request object. Some middleware modules that handle authentication like this are Passport, express-jwt, and express-session. Each of these modules works with graphql-http.

Difficulty: 8/10

Topics: Field-level Authorization, GraphQL Context, Federated Security

Scenario Questions

0-2 years experience

1
Imagine you're building a blogging platform where users can only edit their own posts. How would you pass the user's session token from an HTTP header down to a specific GraphQL resolver to verify their identity before saving?
2
We have a query that returns a list of users, but only admins should see the 'email' field. If a regular user queries the list, how would you handle hiding just that specific field while still returning the rest of the user data?

2-5 years experience

1
We currently have authorization checks duplicated inside twenty different resolvers. A teammate suggests moving this logic into custom schema directives like '@auth(role: ADMIN)'. What are the pros and cons of this approach, and how would you handle cases where the auth check depends on database data, like checking if a user owns a document?
2
A client app queries a dashboard with 5 different nested fields. One of those fields fails an authorization check. How would you structure the GraphQL error response so the client can still render the other 4 fields, and how do you prevent the client from breaking on null values?

5-8 years experience

1
In a federated GraphQL architecture, we need to enforce authorization. How do you decide which auth checks happen at the gateway level versus downstream in the individual subgraphs, especially when a single client query spans multiple microservices?
2
We noticed a major performance degradation on a query that returns a list of 100 items. It turns out our field-level authorization directive is making an independent database call for every single item to check permissions. How would you refactor this to avoid the N+1 authorization problem?

8+ years experience

1
We are migrating a legacy monolithic REST API with centralized OAuth2 and Open Policy Agent (OPA) to a federated GraphQL graph managed by 15 different product teams. How would you design a unified authorization framework that ensures consistent security policies across all teams without bottlenecking their deployment velocity?
2
As our graph has grown, we've ended up with a mix of directive-based auth, resolver-level checks, and gateway-level blocking. This has led to security audits finding leaked fields. How would you design a declarative, auditable authorization strategy for the entire enterprise graph that can be statically analyzed before code is merged?

Follow-up Questions

❓How do you handle nullable fields in your schema design when an authorization check fails?
❓If you use custom schema directives for auth, how do you unit test those rules without spinning up a full server?
❓How does your authorization strategy change when dealing with real-time subscriptions over WebSockets?