Given an authentication mechanism and a signed JSON Web Token (JWT), the @auth
directive tells Dgraph how to apply authorization.
Weβre overhauling Dgraphβs docs to make them clearer and more approachable. If you notice any issues during this transition or have suggestions, please let us know.
Many apps have data that can be accessed by anyone, logged in or not. That also works nicely with Dgraph auth rules.
For example, in Twitter, StackOverflow, etc. you can see authors and posts
without being signed it - but youβd need to be signed in to add a post. With
Dgraph auth rules, if a type doesnβt have, for example, a query
auth rule or
the auth rule doesnβt depend on a JWT value, then the data can be accessed
without a signed JWT.
For example, the to do app might allow anyone, logged in or not, to view any author, but not make any mutations unless logged in as the author or an admin. That would be achieved by rules like the following.
Maybe some to dos can be marked as public and users you arenβt logged in can see those.
Because the rule doesnβt depend on a JWT value, it can be successfully evaluated for users who arenβt logged in.
Ensuring that requests are from an authenticated JWT, and no further
restrictions, can be done by arranging the JWT to contain a value like
"isAuthenticated": "true"
. For example,
specifies that only authenticated users can query other users.
If the ROLE
claim isnβt present in a JWT, any rule that relies on ROLE
simply evaluates to false.
You can also simply disallow some queries and mutations by using a condition on a non-existing claim:
If you know that your JWTs never contain the claim DENIED
, then a rule such as
block the delete operation for everyone.