Authentication - Slash graphql

Documentation
1

All the APIs documented here require an API token for access. A new API token can be generated from Slash GraphQL by selecting the “Settings” button from the sidebar, then clicking the Add API Key button. Keep your API key safe, it will not be accessible once you leave the page.

All admin API requests must be authenticated by passing the API token as the ‘X-Auth-Token’ header to every HTTP request. You can verify that your API token works by using the following HTTP example.

curl 'https://<your-backend>/admin' \
  -H 'X-Auth-Token: <your-token>' \
  -H 'Content-Type: application/json' \
  --data-binary '{"query":"{ getGQLSchema { schema } }"}'
This is a companion discussion topic for the original entry at https://dgraph.io/docs/slash-graphql/admin/authentication/
2

What do I need a client API key for, when I can query the database (from Postman/Insomnia) on my Slash Dgraph instance without providing the client API key? What is the use-case for a client API key?

As I read the documentation, one needs a client API key to query the database, but when I try to query the database from Insomnia - without providing any X-Auth-Token header - then my request is still accepted and processed.

In summary, I fail to understand the following:

  • When interacting with my Slash Dgraph instance, in what situations do I need to provide a client API key? And what will it allow me to do? Will it allow me to read and mutate all data, or only the data that was inserted using that client API key?

(My confusion probably also stems from Securing Your GraphQL endpoint at the same time stating this: “All GraphQL queries and mutations are unrestricted by default” )

Any clarification is much appreciated :slight_smile:

3

Hello,

Thanks for the question.

The client key is required when using the non-graphql endpoints, such as DQL’s /query, /mutate or the gRPC endpoints with a Dgraph client such as dgo.

DQL queries do not honor any @auth rules specified in your GraphQL schema, and hence access to these APIs require this extra layer of security.

We are also building out a simple way to lock down your GraphQL endpoint, and only allow anonymous access to certain operations, and this should go live in a month or so (End Feb 2021).

Tejas

4

Hello,

I’m really surprised that my Slash endpoint is public by default. I tried the same as mortenalbertsen and to my surprise my query was executed without providing my api key. My only option here is to use another database or deploy it locally both of which I would prefer not to do. Any updates on this?

Thanks!

5

Hello,

Sorry for the delay here. We are working on this currently, and we should have this working by the end of feb/early March.

In the meanwhile, the @auth directive will allow you to only allow certain operations without an auth key.

Tejas

6

Hi @gja,

My use case is this - I have a backend API that will only access the database. We may move from Slash hosting to on prem in the future but for now we are using slash. I don’t want to deal with ACLs just yet as that seems very nice but will slow us down in the beginning.

I’m confused by the multiple layers of authentication:

  1. Slash API Key generated from the website
  2. JWT based authentication defined in the schema (e.g. Auth0)

Are these two completely separate? I would like to only access the database using the Slash API token and not use JWT if possible. Is there a way to do just that?

I have this piece in my schema (with sensitive info removed) which seems to at least require the JWT however I would like it to only require the token.
Dgraph.Authorization {"ClosedByDefault":true}

Thank you!
Nick

7

Yes, that’s what we are working on, you’ll be able to restrict which graphql types an anonymous client can access, and use an access key to access other operations

2 Likes
8

Hi, is there an update on this feature?

9

Agree with the other comments here. We should not have the APIs open by default. To that extent, we’ve been redesigning parts of the cloud interface, including this aspect.

@vvbalaji let’s prioritize getting this out this week. Cc @thiyaga @arpan

10

Hi There,

This feature was just released today. You should have a new tab in your schema page which allows you to manage anonymous access.

Tejas

11

We have made a release today that allows the user can now control anonymous access settings in the Schema page. Hope this helps.

12

To add to that, we’re also prioritizing token based auth, which would be a lot simpler to work with. Expect that in a couple of weeks.

1 Like
13

Thanks for moving this forward Manish. I disabled anon-access and using the token successfully now.

1 Like