Optional JWT Authorisation

Users Dgraph Cloud
,
1

Hey folks!

I have schema that includes Users and Groups. The relevant parts are:

type User {
  id: ID!
  sub: String! @id
  displayName: String!
}

type Group
  @auth(
    query: {
      or: [
        {
          rule: "query ($sub: String!) { queryGroup { owner(filter: { sub: {eq: $sub} }) { id } } }"
        }
        { rule: "query { queryGroup(filter: { public: true } ) { id } }" }
      ]
    }
  ) {
  id: ID!
  name: String!
  slug: String! @id
  public: Boolean @search
  owner: User!
}

# Dgraph.Authorization { "VerificationKey": "...", "Algo": "RS256", "Header": "X-Auth-Token", "Namespace": "https://example.com/jwt/claims",  "Audience": ["Auth0ClientID"], "ClosedByDefault": true }

What I’d like is for a query like:

{
  queryGroup {
    name
    slug
    public
    owner {
      displayName
    }
  }
}

to return all public groups, and if a JWT is provided, also the private groups that the current user owns.

When providing a valid JWT into the API Explorer, this works. When I don’t provide an JWT I’m told "message": "couldn't rewrite query queryGroup because a valid JWT is required but was not provided".

So it looks like the JWT is mandatory. What’s the best way to do this so I can have a public response to unauthenticated requests, and a response that includes the extra data when authentication passes?

Thanks in advance!
Ben

1 Like
2

What is your authorization line at the end of your schema (remove sensitive parts). I think you are probably using ClosedByDefault: true which

if set to true , requires authorization for all requests even if the type does not specify the @auth directive.

https://dgraph.io/docs/graphql/authorization/authorization-overview/

3

Thanks Anthony,

I did have that set to true. When I read about that in the docs, I didn’t associate it with being specific to JWT authorisation. I thought it would be like the order deny,allow configuration from Apache, blocking all access unless any @auth directive matched.

Changing ClosedByDefault back to false fixes this.

I think it would still be good to have an option that blocks access by default, without reliance on JWTs, so will look into the best way of adding this as a feature request :smiley:

Thanks again for your help!
B