Authentication and authorization solve two different problems.

Authentication answers: "Who is making this request?"

Authorization answers: "Is this authenticated user allowed to perform this operation?"

For example, a GraphQL request may contain an access token. The server validates the token and identifies the user as user-42. That is authentication.

The server then checks whether user-42 is allowed to update order order-100. That is authorization.

A useful request flow is:

Request
  ↓
Extract credentials
  ↓
Authenticate identity
  ↓
Create GraphQL context
  ↓
Execute operation
  ↓
Authorize requested action
  ↓
Business logic
  ↓
Data source

Do not confuse authentication with authorization. A successfully authenticated user does not automatically have permission to perform every operation.

For example, an application may have these users:

• alice — regular customer
• bob — support agent
• carol — administrator

All three may authenticate successfully, but their permissions can be different.

GraphQL itself does not prescribe JWT, sessions, OAuth, cookies, or any particular authentication mechanism. Those are application and infrastructure decisions.

A common GraphQL architecture authenticates the request before resolvers execute and places the authenticated identity into the GraphQL context.

Conceptually:

const context = async ({ req }) => {
  const token = extractToken(req);
  const user = await verifyToken(token);

  return {
    user,
    requestId: req.headers["x-request-id"]
  };
};

A resolver can then access the identity:

const resolvers = {
  Query: {
    me: (_, __, context) => {
      if (!context.user) {
        throw new Error("Authentication required");
      }

      return context.user;
    }
  }
};

The exact token verification mechanism depends on the application. It could involve a signed JWT, an opaque session token, a gateway, or another identity provider.

The important architectural principle is that authentication should happen consistently rather than requiring every resolver to independently parse and verify credentials.

A context object can also expose an authorization service:

return {
  user,
  authorizationService,
  userService,
  requestId
};

This keeps resolver code focused on API coordination rather than authentication implementation details.

Role-Based Access Control (RBAC) assigns permissions through roles.

For example:

CUSTOMER
SUPPORT
ADMIN

The schema might expose:

enum Role {
  CUSTOMER
  SUPPORT
  ADMIN
}

type User {
  id: ID!
  role: Role!
}

A resolver can enforce a role requirement:

function requireRole(context, allowedRoles) {
  if (!context.user) {
    throw new Error("Authentication required");
  }

  if (!allowedRoles.includes(context.user.role)) {
    throw new Error("Forbidden");
  }
}

Then:

const resolvers = {
  Mutation: {
    deleteUser: (_, { id }, context) => {
      requireRole(context, ["ADMIN"]);
      return context.userService.deleteUser(id);
    }
  }
};

RBAC is easy to understand, but roles can become too coarse as an application grows.

For example, saying that every SUPPORT user can update every customer record may be too broad. Real applications often need resource-level or attribute-level authorization as well.

Role checks alone are often insufficient. Many applications need to determine whether the authenticated user can access a specific resource.

Consider:

mutation UpdateProfile($id: ID!, $input: UpdateProfileInput!) {
  updateProfile(id: $id, input: $input) {
    id
    name
  }
}

Suppose the authenticated user is user-10, but the requested profile belongs to user-20.

A simple CUSTOMER role check would not be enough. The server must verify ownership:

const profile = await profileService.findById(id);

if (profile.ownerId !== context.user.id) {
  throw new Error("Forbidden");
}

This is resource-level authorization.

A more scalable policy might be:

authorization.canUpdateProfile(context.user, profile)

The policy can then consider multiple conditions:

• Is the user the owner?
• Is the user an administrator?
• Is the account active?
• Is the resource locked?
• Does the user's organization own the resource?

This type of authorization is especially important in multi-tenant applications where users from one organization must never access another organization's data.

GraphQL makes field-level access particularly important because clients can request arbitrary combinations of fields allowed by the schema.

Consider:

type User {
  id: ID!
  name: String!
  email: String!
  salary: Float
}

Suppose administrators can see salary, but ordinary users cannot.

A resolver can enforce the policy:

const resolvers = {
  User: {
    salary: (user, _, context) => {
      if (context.user?.role !== "ADMIN") {
        throw new Error("Forbidden");
      }

      return user.salary;
    }
  }
};

This demonstrates an important GraphQL security principle: authorization cannot be applied only to top-level operations.

If a user can access a User object through a permitted query but one field contains sensitive information, that field itself may require authorization.

However, putting large authorization blocks inside individual field resolvers can become difficult to maintain. Larger systems may use reusable policy functions, directives, middleware, schema wrappers, or dedicated authorization services.

The correct choice depends on framework capabilities and application complexity.

As the number of GraphQL operations grows, repeating authorization logic directly inside resolvers becomes difficult to maintain.

A reusable authorization service can centralize policies:

const authorization = {
  canReadUser(actor, target) {
    return actor.id === target.id || actor.role === "ADMIN";
  },

  canUpdateUser(actor, target) {
    return actor.id === target.id || actor.role === "ADMIN";
  },

  canDeleteUser(actor, target) {
    return actor.role === "ADMIN";
  }
};

Resolvers then become simpler:

const resolvers = {
  Mutation: {
    deleteUser: async (_, { id }, context) => {
      const target = await context.userService.findById(id);

      if (!context.authorization.canDeleteUser(context.user, target)) {
        throw new Error("Forbidden");
      }

      return context.userService.deleteUser(id);
    }
  }
};

This separation gives the application a central place to test authorization rules.

For larger organizations, authorization may become a dedicated policy engine or service. Policies can incorporate roles, resource ownership, organization membership, feature flags, geographic restrictions, subscription plans, or other business conditions.

A key principle is deny by default for sensitive operations. New fields and mutations should not accidentally become accessible simply because a developer forgot to add a permission check.