Authentication and Field-Level Authorization — GraphQL in Production

Authenticate at the transport layer (bearer token or session cookie) and put the user in the request context. Enforce authorization in the business/data layer (or resolvers) for every object and field — not just at the top-level query — because the same object is reachable through many paths (order.customer, node(id:), search). Schema directives (@auth(requires: ADMIN)) or policy libraries keep rules declarative; field-level checks protect sensitive fields like emails or costs.

const resolvers = {
  Query: {
    order: async (_p, { id }, ctx) => orders.getForViewer(ctx.user, id),   // auth inside the service
  },
  Customer: {
    email: (customer, _a, ctx) =>
      ctx.user?.id === customer.id || ctx.user?.roles.includes("support") ? customer.email : null,
  },
};

from strawberry.permission import BasePermission

class IsSupport(BasePermission):
    message = "Not authorized"
    def has_permission(self, source, info, **kwargs) -> bool:
        user = info.context["user"]
        return user is not None and "support" in user.roles

@strawberry.type
class Customer:
    id: strawberry.ID
    email: str | None = strawberry.field(permission_classes=[IsSupport])

@Controller
class OrderController {
    @QueryMapping
    @PreAuthorize("isAuthenticated()")
    Order order(@Argument String id, Authentication auth) {
        return orderService.getForUser(id, auth.getName());   // ownership checked in the service
    }

    @SchemaMapping(typeName = "Customer", field = "email")
    @PreAuthorize("hasRole('SUPPORT') or #customer.id == authentication.name")
    String email(Customer customer) { return customer.email(); }
}

Common pitfalls

Authorizing only top-level fields while node(id:) exposes everything.
Authorization logic duplicated (and diverging) in resolvers and REST endpoints.
Error messages revealing that a hidden object exists.

Key points

Auth in context; authorization in business layer
Every path to an object must be checked
Field-level rules for sensitive data

Common pitfalls

Key points

Practice questions