Limit introspection capability programatically

[KyleAMathews]

Many of my types and many fields on some of my types shouldn't be exposed to some subsets of my users. Is there a way to limit visibility on introspection programmatically?

[rdooh]

I have the same general question - how should one introduce authorization (different fields available to different users/roles)? I admit haven't gone through the spec with this in mind though, so I don't know if there's some consideration there. If you have just a few well-defined user-role topologies, then I could imagine actually having multiple type systems, and swapping based on who is making the request. Feels awkward and hacky though. Probably would need to extend the schema to have some sort of authorization function.

[rmosolgo]

Here's my understanding of it: http://rmosolgo.github.io/blog/2015/08/04/authorization-in-graphql/

That's tough for introspection though, since it's mostly built-in!

[devknoll]

@rmosolgo's approach is how I am securing particular queries/mutations/fields. In our case, we don't care that we might expose some authorized user only fields or mutations via introspection. Even if you can see it, you can't run it, so it doesn't really matter.

If I did want to hide that information, I would probably just wrap the object/interface constructors, add some metadata to each field, and just generate multiple schemas per user or per authentication level as necessary. I'm not really convinced this is an issue that the library or spec should try to solve though.

That being said, I wouldn't be opposed to some hooks in the GraphQLSchema to make something like this a little easier, like being able to preprocess types, instead of wrapping them manually.

[rdooh]

Point taken re: scope of library/spec. Might try dynamically generating the type schema.

[KyleAMathews]

I don't see why this wouldn't be something the library handles. Limiting introspection will be a very common need. Also I'll be using scopes for authentication so could have literally 100s of thousands of possible schema combinations.

I really like how Hapi.js handles this. You can set a string or array of strings of scopes on routes that are matched against the user object. Very easy to setup and maintain.

[rdooh]

@KyleAMathews No argument that this is a feature that a full server would need to implement (and that I would love to have in my hands right now). My rough understanding of this project though is to keep this as agnostic as possible, focusing on core GraphQL concepts while letting the community figure out some different ways to implement. The approach you suggest sounds very reasonable, but I'm thinking that deciding on a single methodology for handling authentication at the core might be quite the can of worms. Encouraging growth of an ecosystem without locking in too much is the stage we're at, I think.

Anyway, as to the scale of possible schema combinations you indicate, and assuming there's currently no baked-in solution on the near-horizon, do you think that full introspection of dynamically-generated type schemas could work in lieu of dynamically-limited introspection of a full type schema? I mean, if you could config it similar to Hapi routes. There's probably good opportunity here to write some preprocessors...

[KyleAMathews]

I'd dismissed the idea of dynamically generated schemas as my gut said that'd be expensive to do on every query but after thinking about it a bit more, that should actually work just fine—by far most of the work is in actually executing the query. Stringing together a few objects to create a schema should be very quick.

I noticed your repo @rdooh https://github.com/rdooh/graphql-gateway where you're working on something like this. Will keep an eye on it :)

This isn't something I need to work on right now—just using GraphQL for internal purposes—but will need to move on something in a month or two.

Perhaps I could just add the scope array onto types/fields as I suggested and the preprocessor would take a schema + scope(s) and then "prune" off types and fields that aren't supported. Would that work @leebyron?

[rmosolgo]

Another possibility could be serving different schemas to different people, eg

var schema = user.isAdmin ? fullSchema : limitedSchema 

Depends on how fine-grained the permission levels are though, that would become ridiculous pretty fast!

[tristanz]

I believe FB just returns null for fields that you do not have permission to. Having multiple type systems with fine grained permissions will make code generation, relay, type checking, etc, from GraphQL schemas much harder.

@KyleAMathews why do you need different schemas for 100s of thousands of possible schema combinations? Is it really bad for users to see the full schema?

If you need secret admin only fields for internal use, I'd suggest exposing a different endpoint along the lines of what @rmosolgo suggests. But this seems like a much more limited use case.

[KyleAMathews]

@tristanz I'll be letting people define custom access tokens like

so the number of combinations grows very fast.

It might not be that bad to expose the full schema in some cases but for general cleanliness reasons + also I don't want to have to think every time I add a new field if this is potentially exposing sensitive information to customers or to the public at large (some types will be public)

[tristanz]

Right, but this shouldn't be a schema concern. For code generation, relay, and type checking to work, the schema can't rely on runtime attributes generating new schemas. The schema should just allow nulls. You can then have a middleware layer that uses these tokens to null specific fields and/or short-circuit the resolve logic.

Something like:

resolve: hasPermissions(['user_groups'], resolveFunc)

where hasPermissions returns a resolve function that nulls or short-circuits your real resolveFunc.

[rdooh]

@tristanz, probably there are many cases where allowing users to see the full schema isn't a problem, even if their access will be limited to a subset upon making requests for queries/mutations. That said, sometimes projects have security requirements that are dictated by other stakeholders, and this would reduce the number of battles to fight, even if there is technically no security hole. It's probably not a core concern for this library, but I think there will be use cases for limiting introspection.

(Understand that I'm speculating here, based on imagining trying to rebuild some past projects.)

Dynamic Anyway???
If we ignore the introspection question for a moment, and just think about implementing authorization in general, it seems to me there are roughly two cases: 1) content filtering (e.g. comment list based on owner) and 2) structural filtering of terminal leaf-fields or even whole branches of the schema tree. Both could be handled by arbitrary code inside the resolve function. In fact, the first one probably has to be handled there. But the second one could be handled up front by pruning the full schema tree(s) down to some subspace. There would be some cost to this of course, but I think that a filter function could operate pretty quickly. In same cases things might balance out anyway - an over-reaching query/mutation request against the pruned schema would be rejected outright instead of running through the various (valid) field resolvers and being rejected at some particular point. One can imagine that if you have a request with a lot of sub-actions that can be run in parallel, you might want to avoid kicking them all off if you can catch it earlier. Particularly if there is the potential of having to roll back side effects of mutations.

Anyway, I'm starting to think that dynamic schema generation might make sense in some cases anyhow (provided the cost is low) - in which case the limited introspection question becomes a convenient side effect. Balance of pros/cons will depend on the application of course.

Note
Another potential (small) win for limiting introspection by pruning might be that you can automate testing required data structures for a particular user class against the schema - monitoring whether proposed changes to permissions are going to impact particular use cases.

[rdooh]

Might be going out of scope here - maybe limiting introspection etc is outside of Graph-JS's core mandate, but it's a problem worth addressing elsewhere...

[KyleAMathews]

@tristanz a concrete example of why securing introspection is needed.

Say you're releasing a top-secret new feature. You need to expose new fields and types to support product dev and live testing by a few beta customers. If you can't limit introspection then an aspiring reporter or one of your competitors could easily poke around your GraphQL instance and see what's happening.

Security for data matters a ton obviously but what we're saying is security for metadata matters just as much sometimes.