Hacker News Reader

Comment by delta1 | Hacker News Reader

These guides always ignore authentication/authorization. Is there a standard pattern or way to do these when using GraphQL?

Edit: a quick search for apollo graphql auth turns this up for reading https://www.apollographql.com/docs/react/recipes/authenticat...

View on HN

I ran into the issue of authentication when trying to learn GraphQL. I made a Node/GraphQL/React boilerplate with an example implementation of authentication in place. It's my first foray into both Node and GraphQL so I apologize for any inconsistencies.

https://github.com/johnernaut/express-graphql-react-boilerpl...

This guide really only provides an overview of what GraphQL is so I think it's fair they don't go in depth about auth topics.

If you're curios how authorization can be implemented in a GraphQL server, I recommend the following tutorial: https://www.prismagraphql.com/docs/tutorials/graphql-server-...

Also check out these two awesome projects that provide ways for implementing authorization with GraphQL:

- https://github.com/a-type/prisma-authorized

- https://github.com/maticzav/graphql-shield

If you want to see a practical example of how authorization can be implemented, check out this example project: https://github.com/graphcool/prisma/tree/master/examples/per...

It's simple. In graphql one request matches many routes. That's why when one resolver crashes that field gets null in the response but other fields from other resolvers are still present. (This could cause issues in some apps that would in turn overwrite valid data with a null if the user hits save and the app did not account for null fields).

So for authorization your API simply returns the fields allowed but not the ones disallowed. Auth itself is also covered in the official docs for graphQL and express graphql. You can just put your passportJS user in the context as well as the express request object. Pretty straightforward. Hardest part is retrofitting clients to handle sometimes null fields since graphQL still gives a 200 status code. Clients need to be modified to check for graphQL errors object instead of relying on status codes

For authorization, from what I've seen you'll generally enforce permissions inside resolvers. You can propagate a capability from one field to it's children, which allows you to not have to look up permissions on children fields.

true, the context param in resolvers are the way to do so

I was actually thinking more about passing it as part of the root. For instance, if a person can see all their friends, then you could construct the root for the friend with something like "public only" permission to that person's info, which would prevent someone from accessing private info when checked properly inside the person type.

(Although you certainly can use context at the first resolver, it gets less useful the further down you go imo for authorization)

that also makes sense; and I guess it's just a matter of use-case and preference.

> These guides always ignore authentication

Can't you just use whatever transport-level auth you prefer? I'd assume most GQL queries are over HTTPS so you could use cookies, HTTP Basic, HTTP Digest, a custom HTTP Auth scheme, SSL certs, API keys (through Basic or headers), … the world's your oyster.

Depending on your requirements or constraints, the authorisation would be handled either once at the top-level or on a resolver-by-resolver basis.

I wrote about this last year, https://zach.codes/handling-auth-in-graphql-the-right-way/ it can be pretty easy to do, but nobody talks about it...

Write a parent function that all resolvers go through. you can then add checks if the resolver is public, or whatever you want

well it is a quick guide. auth is a separate topic. Best way to do it is I guess through context in resolvers

Reply on news.ycombinator.com