Logging for authentication issues

Regarding the @auth directives… somewhere I read that authn failures would be logged.

I’m not getting any indication of auth failures in the log. Is there a special flag or environment variable that has to be set?

Not sure, pinging @graphql team.

Bit of an update after hacking around a bit… some errors, such as the fact that a JWT has expired, are returned in the graphql query, but not logged.

Further, if you cock up the JWT in some way and the auth variables are not parsed or the @auth directive blocks access/mutation (rightly so), no error is logged or returned in the query.

More data: if the # Dgraph.Authorization is not loaded correctly from the schema (see Authorization issue when schema is updated via /admin/schema?), the @auth directive (rightly so) blocks the query, but still no error is logged or returned.

Just a thought, when the @auth directive blocks access, maybe a 401 should be returned instead of a 200.

It’s GraphQL, I think all it understands is Status 200.

Right, that makes sense: bound by GraphQL’s protocol.

But maybe the errors field could be populated in the GraphQL results so that normal exception paths in existing code could react accordingly.

I don’t think the errors field is the correct place though 100% of the time.

Use cases:

  • I have access to some contacts but not all, so when I use queryContact I would not want to get an error if I receive no contacts because that could be expected based upon user.
  • However, if I ask for a specific getContact that I do not have access to but does exist, some developers may find it helpful to get a error message, but other developers may not want to expose through error message that something even exists there. Think users with email address as id. Exposing that something did exist but you don’t have access, could potentially open up a security whole because now an attacker knows they have a valid username/email address. Then the attacker can focus on Phishing that user for their password instead of keep on trying to find a valid user. Those developers would want to return null with no error. This use case could easily apply to mutations in the same manner.

Maybe this can be a configurable option? Maybe it should return data in the extension instead of the error

2020 Q3 there was a topic somewhere based upon information getting exposed through error messages and the API was changed to help conceal these errors for the second case above.