GraphQL Authorisation

We are working on a new batch of GraphQL features. One of those is the ability to get your API protected by automated authorisation.

There’s a first version built that we are moving through testing and into a beta release. It’ll be part of beta releases until the release of 20.07.0. We are really keen to get feedback and make this the most useful feature it can be.

Docs and examples will also land pretty soon. But seeing as there’s been lots of interest in this sort of feature I’m putting up this page as a way of recording interest, discussion, feature requests etc.

Authorisation

Firstly, note that this is about authorisation (what you can do), not authentication (who are you) for the GraphQL API.

The basic workings go like this:

  • you set up some mechanism that authenticates you app’s users and provides a signed JWT with claims about that user
  • you add rules to your GraphQL schema that says who can do what and tell Dgraph the public key of the JWT’s signing authority
  • at query/mutation time Dgraph will use the claims in the signed JWT to filter query results and protect mutations from unauthorised access.

Let’s say for example that you are building a todo application. It’s a simple schema, just users and todos.

type User {
  username: String! @id
  ...
}

type Todo {
  id: ID
  owner: User
  text: String @search(by: [term])
  ...
}

You want individual users to be able to see their own todos, but not the todos of other users. So you arrange for the authentication service to provide a JWT with a claim Username and you update the schema with a rule to say that a user can only see a todo if they are the owner

type Todo @auth(
  query: "queryTodo($Username: String) { owner(filter: { username: { eq: $Username } }) { id } } "
) {
 ...
}

The effect at query time of a query like:

query {
  queryTodo(filter: { text: { anyofterms: "graphql" }}, first: 10) {
    text
    ...
  }
}

Is the todos that both match the user’s query and pass the auth rule. In this case, that’s 10 “graphql” todos owned by the user submitting the query.

The consumer of the API doesn’t need to know the rules, or write queries/mutations that are aware of them.

The rules look like graph queries because you can write any rule that you can express as a GraphQL query in Dgraph. That makes for super powerful rules that can take in multiple parameters from the JWT, do arbitrary search in the graph, join multiple conditions, etc.

Going further, you could add isPublic: Boolean to todos and say that a user can query a todo if they own it or it’s public. You can say that users can only update the todos they own, etc.

We’ll post more examples and links to documentation as it comes online. However, if you’ve got questions, feature requests, etc please feel to be involved in the conversation.

9 Likes

Hi @michaelcompton

We have implemented our own automated authorization mechanisms, which are fairly close to what you are proposing here. If you want to chat about our implementation I would love to jump on a quick call.

Best regards,
Joschka.

Oh, hi, that would be great!

I’m mjc in the slack chan, you can send me a personal message there me there and we can jump on a call. I’m australia timezone, so probably your morning, my afternoon would work best.

@michaelcompton I’d like to start using this feature now. Are you saying it is available in some form in a beta instance? Is that in latest, master, or should I look for some other tag?

1 Like

Hi, it’s in the latest master. Docs aren’t complete yet. I expect we’ll have draft docs live on the docs site later this week. If you have to start now, then you’ll need to look at the tests and see if you can make your way forward from there.

I’ll just wait until docs are up. A week is fine. Thanks!