If your app uses GraphQL. You are ready to go. Just spin up a Dgraph Cloud env and good to go. You just need to use all the Auth goodies in your Schema. It will work like a charm after you design your schema model.
If you wanna use DQL on the other hand. You gonna have to build an API. And there are other extra steps to secure your GraphDB.
Hum, you are probably looking for GraphQL indeed. The Auth feature supports some third-party auth. I’m not 100% aware of this, I gonna ping @amaster507 .
@pbassham built a very small proof of concept for us with Swift. To be clear it was a very basic functionality to see how the sign-in and query process works. I am Windows based and he (pbassham) is iOS based, so that was his baby. We sidelined that while we focus on getting our main web app built first and relaunched.
I don’t think he tried any single sign on, we haven’t really integrated our sign-in process with anything 3rd party yet. We are just managing it all ourselves with a lambda (not hosted in Dgraph Cloud) to serve JWTs from our own Dgraph database. It should be available though. Check out
All you need is a signed JWT containing the user’s information and roles that is needed by your custom GraphQL authorization rules.
From our little experiment without getting too far into it, we did find though that the GraphQL queries themselves required a much more static approach. Sometimes we dynamically build queries but the approach that we found with swift is that the queries had to be very statically defined up front and then modified with variables such to skip or include fields. Again, I am very very far from knowing anything about swift though and there may be other ways to do it than what we initially found.
To answer directly…
Dgraph Cloud can provide the GraphQL API endpoint that can be secure with @auth rules. Set this up and you will not need another backend server for the majority of use cases.
To clarify again. Dgraph’s Cloud GraphQL API (right now) does not do authentication, but only does authorization. One you authenticate a user in your app using some other method and have an authenticated signed JWT containing the user’s identification and any data needed for your business authorization rules, then you simply pass this JWT to the GraphQL API generated by Dgraph and it compares the signature of the JWT for validity and then runs the rules you have provided for the query that is being performed and will only allow the actions (add, update, delete) you authorize and return the data (query) that you authorize by your rules.
For more information concerning the Dgraph @auth directive see:
Thank you for the feedback. Based on your response then, would something like the image below work? In words, from the iOS app, perform user authentication using whatever 3rd party login. If login is successful, send a request to a backend to create a JWT and use that JWT to perform queries to Dgraph.
My only question is how to refresh the token and monitoring if it has expired.
If you use something like firebase auth iOS, it is exactly the same premise as in a web app. Your backend stays the same, create a firebase token with the firebase api, and connect exactly the same way as you would in a web app. Done.
Custom Claims would still be done in a firebase function (on create user).
FWI: IMHO, I personally would design an app using Flutter instead of iOS, as it will immediately work on Android and iOS, and it is quick to save mucho dinero.
You can wait to get an error for when the token expired from Dgraph when you make a request or you can decode it and look at the expiration in your app. To refresh your token that varies based upon what service you use for authentication. I believe firebase and auth0 both support refresh tokens. The basic premise is that when you authentocate you get a refresh token and then you use that refresh token to get a shorter lived token with your custom claims, you check in your app for the expiration and use the refresh token to get another short lived token all blindly to the user.