Authorized AppSync Subscriptions

High security walls in Paris — Kemal Ahmed (me)

How can we make subscriptions in AppSync with regard for security?

Before I go into it, AWS AppSync is a GraphQL backend service by Amazon. AppSync subscriptions are webhooks between your client and the server. In plain English, when your data changes, your front end changes immediately without the need for polling.

When you enable subscriptions, you don’t want users to be able to subscribe to private data updates of other users. You want to ensure only a single user has access to their data. For this demo the users are authenticated through Cognito and I’m using DynamoDB to store the data.

In this example, we have a set of parents who forget their children’s names.

Hey…you! Go to your room!

1. Specify who is subscribing

Make a parameter that specifies the user who is making the request to subscribe. Add the parameter in the mutation as well as in the subscription itself.

The schema could look like this:

2. Auth-guard the Mutation

In the resolver, make sure to authorize the user within the mutation. I did this in a number of ways.

1. I don’t let the mutation occur if the parentId parameter doesn't match the authorized username. This is the first line of defence to prevent faking on the update mutation.
2. I set the parentId as a sort key. This makes sure that only the parent has access to their kids on the database. If you don't do this, make sure to still add it as an attribute and do step (3).
3. I check that the resulting parentId is the same as the request identity. This is more useful if you don't use parentId as a sort key because you can't trust that the parentId the user is sending is the value associated with the child.

Example request resolver:

Example response resolver:

3. Lie detect in the subscription resolvers

Will the user be able to receive change events with the security we already have?

Yes. If a parent hacks the client and enters the wrong parentId (or the right one if you're spying!), they will receive change events because subscriptions just send back the response from the mutations based on the user making the mutation, not based on the user subscribing to the mutation.

To stifle the malicious parents, add a resolver to the subscription that lie detects the requesting parent. You can do any operation you want here:

I tried doing empty operations, but AppSync doesn’t permit this, so I just did a scan with a limit of 1:

Don’t worry about authorizing the response because you aren’t asking for a parentId to be sent back:

Just put null.

And with that, your subscriptions and mutations are secure from nosy parents.