I have a question about best practices around using a single Dgraph Cloud API as the backend for multiple sites.
Given I have main.site, foo.site and bar.site and they all use the same Dgraph Cloud API, then would it be a bad idea for the user to be logged into all 3 sites after logging into one? i.e. One JWT that is used to auth a user against the GraphQL as well as all of the websites.
Or would it be better for users to have to log into each site individually and generate an individual JWT for each site, even though this JWT used to auth against the same Dgraph Cloud instance?
How I imagine the second scenario working is to create a psuedo-single-sign-on that works like this:
User visits foo.site
User clicks a button that says “Login with main.site”
I think sites like Stackoverflow and Superuser use different login systems, but make it possible to use the same login across all sites. Under the hood, they use different Databases, but copy the login information from one site to another (I believe).
Firebase Auth and Auth0 require you to re-login for each different domain (because your browser stores the data per domain), but you could still share the same login information (user / pass / provider).
Basically, there are ways to hack this, but it is not recommended as it is not secure.
Keep the login flow simple, share the same login backend, but the sessions won’t persist for a good reason.
Either way, they shouldn’t have to sign up twice, just re-login.
Why not just use different parts of the same namespace and add in a variable in the jwt for which site is logged in then you can use that in your auth rules.
You could also then decide to let some people login once and access to both and restrict others however you want to generate the jwt.
IMO this is not a problem with the db, but rather just a use case of how to generate jwt and write auth rules.