How do you handle authorization in a GraphQL API?
Assesses fundamental understanding of GraphQL conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Authorization belongs in the server layer, never in the client query. Because clients can request any combination of fields, enforce rules at the field and object level, not only at the endpoint.
Common approaches:
- Check permissions in the
contextwhen building it, then re-check per resolver for sensitive fields. - Use schema directives such as
@auth(requires: ADMIN)applied to fields or types, backed by middleware that wraps resolvers. - Return typed errors or null for fields the caller cannot see, and never expose existence of unauthorized data.
type Query {
salary: Int @auth(requires: HR)
}
Beware of leaking data through error messages, counts or relation traversal. Centralize policy in a reusable authorization service, test it per field, and audit new fields because introspection and tooling make the schema map easy to discover. Rate limiting and query cost analysis complement authorization but do not replace it.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.