Password auth rule in @auth directive

Users GraphQL
1

Hi!

I have trouble to understand how to use simple password authentication within the @auth directive. The documentation only states:

" Additionally, you can use this directive with the @secret directive; and, if you specify a password authorization rule, Dgraph will use it to authorize the check<Type>Password query."
See: https://dgraph.io/docs/graphql/authorization/directive/#sidebar

But how do I implement it? Does someone has an example?

best reagrds
Niclas

1 Like
2

The type doc itself has an example Types - GraphQL

This is an extension of https://dgraph.io/docs/query-language/schema/#password-type

If you need more about auth see this

3

mh ok, sadly I did not get it running. I tried:

type Member @secret(field: "token") @auth(password: {rule: """
    query($PASSWORD: String!, $USER: String!) {
        checkMemberPassword(username: $USER, token: $PASSWORD){
            username
        }
    }
"""}){
    username: String! @id
    rooms: [Room] @hasInverse(field: "members")
    name: String
}

But I get:

resolving updateGQLSchema failed because Type Member: @auth: expected only queryMember rules,but found checkMemberPassword (Locations: [{Line: 3, Column: 4}])'

And where is the difference between using @auth with password or query authorization rule?

4

Update: My new theory is that maybe this is so you can have a built-in login system with Dgraph. And not having to create your own. Or depend on third parties login systems.

Well, I donā€™t know why they supported Password type in GraphQL. I have no idea. I also donā€™t know how it would work with Auth. However, I will explain the difference.

Password type has no authorization setting. It obscures only one predicate - the password itself. The rest is not protected by anything. This type only serves to store passwords. Nothing more. In the past it was used to create manual login systems. I mean, thatā€™s still how itā€™s used. The use of this type is free, you can do whatever you want with it.

However, this implementation they made in GraphQL I didnā€™t understand the purpose. I need to analyze the PRs to understand what they wanted with this. Thatā€™s a lot to cover.

Some links:

On the surface, thereā€™s nothing too much or fancy with this Type. I donā€™t understand what connection Docs makes between secret and auth.

Quickly analyzing the links above, it seems to me that there is something that connects the two things. But I still donā€™t know the whole thing. Thereā€™s a lot, and tests to dig into and understand.

TIP:

To search for specific things in the repo and even find tests. I make a clone of the repository, I use VsCode. I use the VSCode search engine(cmd+shift+F) and search for example for ā€œ@secret(ā€. So I can see where it is being used. And with the ā€œgitblameā€ extension I can identify which PRs they came from.

5

Apparently you canā€™t create your own query. Dgraph does this automatically. GraphQL Schema does not need to indicate ā€œcheckMemberPasswordā€. My suspicion is that this will be generated automatically and you can see it in the GraphQL Schema when you generate it.

An example from e2e(end to end) tests files

type User @secret(field: "password") @auth(
  delete: { and: [
    { rule: """
    query($USER: String!) {
        queryUser(filter: { username: { eq: $USER } }) {
        __typename
        }
    }
    """ },
    { rule: """
    query {
        queryUser(filter: { isPublic: true }) {
            __typename
        }
    }
    """}]
  }
){
  username: String! @id
  age: Int
  isPublic: Boolean @search
  disabled: Boolean
  tickets: [Ticket] @hasInverse(field: assignedTo)
  secrets: [UserSecret]
  issues: [Issue]
  tweets: [Tweets] @hasInverse(field: user)
}
1 Like
6

@Jan-Niclas_Gladbach what problem are you having? Just trying to use a password fields to write an auth rule? I would be careful about using it in a @auth rule, because that means the password would be in your jwt as clear text always. I would write a mutation script that checls the password using that query not in an auth rule and generate a jwt token that is authorized but does not contain the password. I wrote some articles around this :wink:

For simplicity I didnā€™t use the password field or specially generated functions to check the password But, you could enhance what I had to add those things somewhat easily.

7

Hey, thank you for all the help!
The dgraph documentation makes the impression that the auth system is very flexible, but after a lot of tinkering, the way described in your article seems to be the only working one. And the only truly secure one.
I will implement it exact this way now :ok_hand:t2:

The documentation conveyed the picture, that the authorization is more like the firebase way, where I can check the parameters within the user request. The documentation could be a bit more strict.

Thank you very much for your help, I will implement this for now and open a new ticket if I come across any errors. We can close this one :slightly_smiling_face: