It really is a shame, that the GraphQL specs don't have pagination and auth. ( https://github.com/facebook/graphql/issues/4 ) It would have finally ended the bickering about how to design "RESTful APIs", there's the specs, that's it. (Sure, there are a dozen REST-ish API descriptors and schema thingies, but they got nowhere, as far as I know.)
Pas, who you are responding to, used the more ambiguous abbreviation of "auth", but I was specifically referring to authorization, not authentication. So once you are authenticated, i.e. once I know who you are, what are you allowed to do? This is a deeper, ___domain-specific question, and the GraphQL guide rightly points out that this doesn't belong in whatever glue layer exists between your ___domain logic and the schema you expose.
My question was essentially for both expansions of auth. Because as far as I'm concerned, as long as your API layer provides some means of determining user identity, everything else related to auth should be the responsibility of lower layers. It was largely a rhetorical question, because people have been asking for GraphQL to solve non-GraphQL problems since 2015.
Do you mean HTTP as the lower layer? I can see authentication (or better said session persistence) handled by a HTTP header, but I don't really see how HTTP by default provides options for what mutations and queries the client should be able to issue. There's no ACL descriptor for GraphQL.
And even the choice of HTTP header for Authentication is debated enough, that I think it should have been bolted down in the GQL specs.
