Graphql-engine: docs: guide on keeping authentication/roles tables in the same database

[heyrict]

As is discussed in other issues like #1446, most applications will use the same database for User and other tables, thus the authentication server will share the access to the same database with hasura backend. So it will be good to have an optional built-in authentication endpoint in the hasura graphql engine.

One option is to have a customizable authenticate function similar to what graphile use in postgre db.

[mnlbox]

@heyrict I also like to see an official integrated approach for authentication but it's not very difficult. You can also use other solutions like HB+: https://github.com/elitan/hasura-backend-plus

[heyrict]

Thanks to @mnlbox for providing the alternative solution.

Hasura backend plus shares the same limitations with the official auth-server
According to the hasura spec, we can have multiple roles and can change them with a post header update, which has yet not been implemented.

Traditionally we have a Role table with many-to-many relationship to User. Tuning the auth-server to generate multiple roles and accept role switch is tricky and time costly.

[coco98]

@heyrict We need to update our docs to talk about different ways of modelling roles. This has long been pending.

I'm listing out some points here in case this is helpful to you:

• If your roles and user information is in the database, then in the JWT token you should assign all roles to every user.
• Now let's say you have a table called document. Each document has an owner, editor and viewer
• Each user has the roles: owner, editor and viewer
• There is a document_editors and document_viewers table that has document_id, user_id columns. So the editors of a particular document are in the document_editors table.
• Now when you make a graphql query as an editor it will automatically only apply to those documents that are editable by the particular user, because the editor permission for the document is update if document.editors has current_user_id.

Does this makes sense / solve the problem?

[heyrict]

@coco98 Thank you for your clarification. I have edited the issue message to avoid confusion.

The reason I opened this issue is that I found it inconvenient to get a working authentication server especially for new hasura users.

To clarify, the current authentication process is:

• setup hasura
• design the database in hasura console
• setup auth-server
• customize auth-server to fit the database you designed (this step is not starter-friendly)

While what I think will be more convenient is:

• setup hasura
• design the database in hasura console
• select the authentication logic in hasura console

I don't know if implementing an integrated authentication will be difficult, but I think it is a good choice and worth discussion.

[coco98]

Immediate thing for us to do: Document and share a boilerplate (with say zeit) on how to have users/roles and authn features in the same database as the application data (which Hasura is using).

[mnlbox]

@coco98, @marionschleifer I think if we can enable/disable this (for example called basic_authentication) as a flag in console and setting page or through environment variable it can be very useful too.
Something like #2240 but at database level.
If you like this I think maybe it's better to create new feature request called basic_authentication.

[sarendsen]

It would be very helpful to be able to auth against the local instance from a table/view or function.
One of the trademarks of hasura is speed. And having to authenticate against a remote source creates unnecessary overhead. And in some cases JWT is not available because of existing flows. (token authentication, sessions etc)

[revskill10]

I don't know how can you avoid the nessesity of setting a custom auth server. One important point is to set secure cookies within the same domain. So the Auth server must be on the same domain as your application (more specific, auth is just an API). Hasura is often on another domain, so i don't know what's the real world use case of putting an integrated "basic authentication" inside Hasura for.

Another important point, is, for real world enterprisey application, you often don't have any roles table. The role is determined dynamically based on a custom condition of user's properties. So i don't think this feature is generic enough to be actually useful in real world. In my project, role is determined dynamically, and each role has a set of custom headers to be sent from client.

For a better suggestion to the author of issue: If you can provide a real world use case , it's easier for Hasura team to adopt an implementation that we can use.

[richcorbs]

I would like to +1 this feature request for an opt-in postgraphile-like basic authentication function inside of Hasura (and other supporting function like password change and user creation with password). For the following reasons:

• At the stage my project is in I don't want to maintain a separate server or integration with a 3rd party for auth/JWT. Nor does my project have a need for advanced features.
• The speed of Hasura adoption would increase dramatically. Hasura would be even more game-changing than it already is!
• When a project gets to the point where basic auth isn't enough it can grow into more advanced solutions. It seems like a natural progression. Not every project needs (or knows it needs) advanced features.
• Having the option to use a basic authentication function opens up a lot of possibilities for projects that are just getting started and doesn't bind them to the more advanced solution.
• Postgraphile has proven that an authentication function is doable.

Honest question: In a JWT solution "secure cookies" are not a concern, correct?

I think I would be happy with either JWT-based or session-based solution as long as I had access to the user attributes in the permissions tab.

Thanks for letting me chime in. :-)

[rishavs]

Having a basic session based auth baked into Hasura would be very much appreciated. spinning a new server just for auth makes no sense and essentially forces me down a path I don't need to take.