GraphQL Field Guide to Auth
Matt Krick

Finally, someone also going through the auth process. Here’s how I’ve done it so far (a lot of similarity):

First, the endpoint is protected via JWT. Errors at that level are basically the same as I return for REST (HTTP 401, 403, etc).

Second, I implement a similar top-level query auth. Is the user even allowed to access this query? Further, if the query returns a list of objects that are user-specific, return only the objects the user has access to.

Third, field-level auth, option A. The inexpensive way I do this, is to expose certain queries, that already filter out the sensitive fields. So I might have a project query, and a publicProject query. If the user is authorized to access the publicProject query via query-level auth, then I don’t have to think about the fields because they were already vetted.

Third, field-level auth, option B. The more expensive way, is to check the conditional fields as needed. If you follow the “viewer” pattern, the viewer gets passed around like the village bicycle, and fields are checked against that viewer. If your permission system is simple, then I guess this is fine. For us though, the fields you have permission to see, are based on the role you have in a group you have been assigned to, and what role that group has on a project. That requires DB checks, and while that can be cached to some extent, it’s definitely a performance hit. I try to avoid that by using the “cheap” method above.

Per the error convention, I tend to like the idea of repurposing REST HTTP errors. So the errors response array might have an error of {message: "Permission Denied", code: 403}. Looks like GraphCool is just making their errors up as they go along. Not really sure how GitHub is handling errors in their new GraphQL API, or how Facebook does it.

Like what you read? Give Bobby Juncosa a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.