Schema stitching for server to server access with more privileged access.

[alloy]

There’s a need for MP offering 2 schemas (see here and here), one for consumer clients and one for more privileged server to server access. The latter contains fields of which even the existence shouldn’t be leaked publicly.

1. One possible solution would be to have MP use 2 client app ID, one for each access level, and then on startup ask services for their schemas using both of these IDs, stitch them together; and then on each request check if the user is authenticated, if they are then check their access level, and finally execute the request against the correct schema.

   However, seeing as MP is OSS and stitching code refers to field names, it would be pretty much impossible to stitch together the more privileged schema without leaking field details through MP’s source being publicly readable.

2. Another possible solution for this would be to have a second closed-source app (with its own app ID) that would import all of the MP source and only there extend the more privileged schema by referring to private fields. (This could potentially also remove the need for checking a user’s access level on each request, if we can have this shadow MP only accessible at the network level by privileged apps?)

In either case, MP would not allow a client to query for fields that do not exist in a service’s introspected schema, as from MP’s perspective during query execution these fields simply don’t exist.

Any other solutions or further thoughts?

[alloy]

This does mean that backend services still need to be able to serve different schemas based on the provided app ID.

[alloy]

It looks like at least graphql-ruby has the built-in capability to limit visibility, so I assume this means that if we make use of that the service will automatically respond with the correct schema (for the client’s authorization) in response to an introspection query 👍

[ashkan18]

few things to consider:

• This assumes we'd only have two levels of authorization, public or trusted. This is correct in case of Gravity at the moment, but just a limitation to consider. Imagine that tomorrow we wanted to show specific set of fields if you are a licensed app or something.

• Having a closed-source MP might actually be useful when it comes for our internal apps, in few areas currently Volt plays metaphysics role to call few services and serve it's pages, our internal facing apps could benefit from closed-source MP potentially.

[alloy]

• This assumes we'd only have two levels of authorization, public or trusted. This is correct in case of Gravity at the moment, but just a limitation to consider. Imagine that tomorrow we wanted to show specific set of fields if you are a licensed app or something.

It assumes that there’s only a very limited amount of them and not many permutations based on e.g. specific users.

Closed-source MP could hold several schemas for various privileged roles, as described in option 1, if that makes sense for the problem at hand.

• Having a closed-source MP might actually be useful when it comes for our internal apps, in few areas currently Volt plays metaphysics role to call few services and serve it's pages, our internal facing apps could benefit from closed-source MP potentially.

Closed-source MP would basically only have to exist for these purposes. Until there are apps that want to consume a stitched together privileged schema there’s no need to build this app yet.

[alloy]

An interesting note that came out of chatting to @ashkan18 was that this is only about knowing about the full schema, not whether or not a particular app/user may read values from all of the fields in the schema.

So while we don’t want external people to be able to know of the existence of fields or read their values, I think that it should be fine for our services to know that certain privileged fields exist. The service powering that field may still decide not to allow an authenticated app/user to read from those fields.