← GraphQL Course11 / 12

Authentication & Authorization

Secure your API — identify the caller once in the context, then enforce permissions inside resolvers and at the field level, where authorization actually belongs.

Ad 728×90

Authenticate in the context

Why: the context function runs once per request, before resolvers — the right place to read the auth token from the HTTP headers, verify it, and attach the user. Every resolver then sees ctx.user. Authentication (who are you?) happens here, once.

await startStandaloneServer(server, {
  context: async ({ req }) => {
    const token = req.headers.authorization?.replace('Bearer ', '')
    const user = token ? await verifyToken(token) : null
    return { user }
  },
})

Authorize inside resolvers

Why: authorization (what may you do?) belongs in resolvers, where you know the user AND the data. Check ctx.user and throw a FORBIDDEN error when access is not allowed. Do NOT rely on the client hiding a field — the server must enforce it.

import { GraphQLError } from 'graphql'

const resolvers = {
  Mutation: {
    deleteBook: (_p, { id }, ctx) => {
      if (!ctx.user) {
        throw new GraphQLError('Not authenticated', {
          extensions: { code: 'UNAUTHENTICATED' },
        })
      }
      if (ctx.user.role !== 'ADMIN') {
        throw new GraphQLError('Forbidden', {
          extensions: { code: 'FORBIDDEN' },
        })
      }
      return db.books.delete(id)
    },
  },
}

Field-level authorization

Why: sometimes only one field is sensitive — a user's email is public to themselves but hidden from others. Put the check on that field's resolver, returning null or throwing based on the viewer. Authorization is per-field, not just per-operation.

const resolvers = {
  User: {
    email: (user, _args, ctx) => {
      // only the user themselves (or an admin) sees the email
      if (ctx.user?.id === user.id || ctx.user?.role === 'ADMIN') {
        return user.email
      }
      return null
    },
  },
}

A note on the single endpoint

Note: because GraphQL has one endpoint, you cannot secure it with per-route URL rules like REST. Security lives in the schema and resolvers instead. Also guard against abuse the open graph enables: limit query DEPTH and COMPLEXITY so a deeply nested query cannot become a denial-of-service. Libraries exist for both.

REST:    secure each URL/route
  GraphQL: one endpoint → secure in resolvers + the schema
  also add: query depth limit + complexity limit (anti-DoS)

Authenticate in the context

await startStandaloneServer(server, {
  context: async ({ req }) => {
    const token = req.headers.authorization?.replace('Bearer ', '')
    const user = token ? await verifyToken(token) : null
    return { user }
  },
})

Authorize inside resolvers

import { GraphQLError } from 'graphql'

const resolvers = {
  Mutation: {
    deleteBook: (_p, { id }, ctx) => {
      if (!ctx.user) {
        throw new GraphQLError('Not authenticated', {
          extensions: { code: 'UNAUTHENTICATED' },
        })
      }
      if (ctx.user.role !== 'ADMIN') {
        throw new GraphQLError('Forbidden', {
          extensions: { code: 'FORBIDDEN' },
        })
      }
      return db.books.delete(id)
    },
  },
}

Field-level authorization

const resolvers = {
  User: {
    email: (user, _args, ctx) => {
      // only the user themselves (or an admin) sees the email
      if (ctx.user?.id === user.id || ctx.user?.role === 'ADMIN') {
        return user.email
      }
      return null
    },
  },
}

A note on the single endpoint

REST:    secure each URL/route
  GraphQL: one endpoint → secure in resolvers + the schema
  also add: query depth limit + complexity limit (anti-DoS)