Authentication and Authorization in GraphQL with Spring Security

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Use Spring Security for authentication (JWT or session-based) at the HTTP layer — GraphQL is just HTTP. Authorization can be done at the resolver level with @PreAuthorize annotations, or at the schema level using a custom instrumentation or a library like graphql-java-extended-scalars. Keep auth logic in the service layer, not in resolvers.

Interview Answer2 min

Authentication in a GraphQL Spring Boot API is identical to REST — a JWT filter validates the bearer token before the GraphQL engine sees the request, and the result goes into the SecurityContext. Authorization is where the GraphQL-specific concerns appear.

Why URL-based auth rules don't work:

With REST you can write path-based rules like /admin/** requires ROLE_ADMIN, but with GraphQL every operation hits the same /graphql endpoint — URL rules cannot distinguish a public query from an admin mutation
The solution is method-level security: @PreAuthorize on resolver methods — a query requires isAuthenticated(), a delete mutation requires hasRole('ADMIN')

The silent failure — `@EnableMethodSecurity`:

Without @EnableMethodSecurity, @PreAuthorize annotations are silently ignored — everything appears to work, but no role checks actually run
This passes code review because tests typically don't exercise authorization boundaries; always write a test that verifies an unauthenticated call is rejected

Error mapping:

When @PreAuthorize rejects a call, Spring throws AccessDeniedException; GraphQL always returns HTTP 200, so without explicit handling this becomes a generic INTERNAL_ERROR that clients can't distinguish from a server bug
Register a DataFetcherExceptionResolver that converts it into a typed FORBIDDEN error with an extensions.code field so clients can react programmatically

Field-level authorization:

Inject @AuthenticationPrincipal to get the UserDetails directly in resolvers — keeps the resolver testable without SecurityContextHolder
Field-level auth for sensitive fields like salary or email belongs in the service layer, not the resolver — it allows reuse across resolvers and prevents auth logic from being tightly coupled to the schema shape

I recommend writing authorization tests that verify specific extensions.code values on rejected operations — without them, auth failures are indistinguishable from server errors for both clients and your own monitoring.

Interview-ready guide

Interview answer

Why URL-based auth rules don't work:

With REST you can write path-based rules like /admin/** requires ROLE_ADMIN, but with GraphQL every operation hits the same /graphql endpoint — URL rules cannot distinguish a public query from an admin mutation
The solution is method-level security: @PreAuthorize on resolver methods — a query requires isAuthenticated(), a delete mutation requires hasRole('ADMIN')

The silent failure — `@EnableMethodSecurity`:

Without @EnableMethodSecurity, @PreAuthorize annotations are silently ignored — everything appears to work, but no role checks actually run
This passes code review because tests typically don't exercise authorization boundaries; always write a test that verifies an unauthenticated call is rejected

Error mapping:

When @PreAuthorize rejects a call, Spring throws AccessDeniedException; GraphQL always returns HTTP 200, so without explicit handling this becomes a generic INTERNAL_ERROR that clients can't distinguish from a server bug
Register a DataFetcherExceptionResolver that converts it into a typed FORBIDDEN error with an extensions.code field so clients can react programmatically

Field-level authorization:

Inject @AuthenticationPrincipal to get the UserDetails directly in resolvers — keeps the resolver testable without SecurityContextHolder
Field-level auth for sensitive fields like salary or email belongs in the service layer, not the resolver — it allows reuse across resolvers and prevents auth logic from being tightly coupled to the schema shape

03 · Deep dive