Access control

Access control in any API is about the definition of who can do what. For example, there might be users who can add or remove other users, or some data is only accessible to one group but not to others. This is especially important for multitenant applications where you have data for multiple customers available in a single API. But some sort of access control is needed for almost all real-world use-cases.

GraphQL is about graphs, so it helps to think in nodes (objects) and edges that connect them. This way, the main question of access control is: what nodes a user can reach?

In this chapter, we'll explore the various approaches to control access in a GraphQL API. The methods here are generic to all GraphQL implementations, and not just AWS AppSync.

Example data model

In this chapter we'll use a data model that has Users, Groups, and Articles. Users belong to groups, and these provide strict separation, such as Slack workspaces. Users in one group should not know about users in another group.

Users in the same group can be friends. This provides a link between the User objects.

Finally, users can write articles. These are public, so articles published by a user in a group can be read by users in another group too.

The schema for these types:

type User {
  username: String!
  friends: [User]
  # we'll use this to see
  # how a naive implementation can be insecure
  group_unsafe: Group
  group: Group
}

type Group {
  name: String
  users: [User]
}

type Article {
  text: String
  author: User
}

Then the API allows these queries:

type Query {
  user(username: String!): User

  allUsers: [User]
  @aws_cognito_user_pools(cognito_groups: ["admin"])

  allArticles: [Article]
}

Entry points