4 ms·

GraphQL really needs a gateway like Envoy to give better observability / control / auth, and indeed that’s how lots of people deploy it.

x86x87 3y ago
Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.
- andrewingram 3y ago
  By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
  - foota 3y ago
    I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
- pravus 3y ago
  I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.
- tomtheelder 3y ago
  Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.
- seanp2k2 3y ago
  https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.
- ewalk153 3y ago
  This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html
- deecewan 3y ago
  > Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".
politelemon 3y ago
Is it not possible without Envoy? IMO this feels like a failing if I'm relying on a separate piece of software. I'm comparing it with RESTish services which are easily scaleable in many ways either software or infra. But that might be my misunderstanding of what you just said
- seanp2k2 3y ago
  It’s something that’s handled a lot these days at BigCos by service / query gateways / proxies and in the places that utilize these heavily it’s pretty automated from my experience. Basically the dev experience is you go into some web ui or make a PR against some JSON / yaml policy to allow whatever then it just works because some other sec / infra team plumed in all the auth and access control parts. GQL itself doesn’t attempt to solve authZ or authN by design. Edit: if you want to do this with nginx or within graphql / express, this is what that could look like https://www.apollographql.com/blog/backend/auth/a-guide-to-authentication-in-graphql/ https://www.apollographql.com/blog/backend/auth/a-guide-to-a...

x86x87 3y ago

Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.

andrewingram 3y ago
By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
- foota 3y ago
  I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
pravus 3y ago
I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.
tomtheelder 3y ago
Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.
seanp2k2 3y ago
https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.
ewalk153 3y ago
This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html
deecewan 3y ago
> Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".

politelemon 3y ago

Is it not possible without Envoy? IMO this feels like a failing if I'm relying on a separate piece of software. I'm comparing it with RESTish services which are easily scaleable in many ways either software or infra. But that might be my misunderstanding of what you just said

seanp2k2 3y ago
It’s something that’s handled a lot these days at BigCos by service / query gateways / proxies and in the places that utilize these heavily it’s pretty automated from my experience. Basically the dev experience is you go into some web ui or make a PR against some JSON / yaml policy to allow whatever then it just works because some other sec / infra team plumed in all the auth and access control parts. GQL itself doesn’t attempt to solve authZ or authN by design. Edit: if you want to do this with nginx or within graphql / express, this is what that could look like https://www.apollographql.com/blog/backend/auth/a-guide-to-authentication-in-graphql/ https://www.apollographql.com/blog/backend/auth/a-guide-to-a...