When using Auth0, newly registered users will likely need to be stored somewhere in your own systems so that you can store more data about them. This means Auth0 needs to send data about users that register through its services to your own services.
Auth0 will also provide the JWT that specifies exactly what roles a user has, like what they are permitted to see or update in the database. After configuring them, you can specify what roles can see or update what data inside of the Hasura console.
Kyle Gill: [0:00] To prevent anyone with your endpoint from writing to and accessing any data in your database, you can enable JWTs, sometimes spelled out JWTs, in Hasura by adding another environment variable. Configuring what users can see what data sometimes referred to as authorization.
[0:18] Navigate to where you have Hasura service setup. In my case, that's Heroku. Add a new environment variable called HASURA_GRAPHQL_JWT_SECRET. You need to generate the value for the key to include here, and you can do so at hasura.io/jwt-config. Select Auth0 is the provider, add your Auth0 domain, then generate and copy the output back into the value for the variable.
[0:53] This will enable JWTs on the Hasura site, and data will not be accessible unless the user provides a JWT or the admin secret.
[1:02] Now, go to Auth0. Navigate to the section called rules. We'll add two new rules, one to insert a new user into the Hasura database, and one to attach the proper permissions to that user's JWT, so that Hasura can identify what the user is authorized to access.
[1:30] Hasura has a doc on integrating Auth0 that you can reference, but I've written and included the function need to run in the Auth0 folder and the example repository for this project. I copied into the Auth0 rule. This function will hit your GraphQL endpoint with an insert user mutation. These refer to the same URL generated by Hasura as well as the insert user mutation generated by Hasura.
[2:02] Then it forms the request and posts to your endpoint using your admin secret to authenticate. Make sure that you include your own Hasura endpoint and change the admin secret to your own admin secret saved as the environment variable on your Hasura instance.
[2:20] You can now try this rule with Auth0's built-in debugging to verify that their demo user passed into the rule, gets inserted into your database. You can see this user in the first row, J Doe, matches up with the sample data sent by the rule.
[2:39] The final step is configuring exactly what data is queryable and writable for specific users in the tables permissions tab of Hasura.
[2:48] This can vary by app, but for my app, I want some data like playlists to be accessible to unauthenticated users, and other data like inserting playlists to be restricted to logged-in users.
[2:59] In the permissions tab for playlists, make all data selectable to the public role, which is the same name of the value we gave the environment variable on Heroku for unauthorized access. Choose without any checks to say that any user can access it, and toggle all columns as accessible.
[3:18] Add another role called user that refers to any logged-in user. This should have the same select permissions as public users, but should also be able to insert new playlists without any checks.
[3:35] Now go to the upvote tables permissions, and give it the same select permissions. However, upvotes should only be able to be inserted or updated by users who added them. You can do this by adding a custom check on the insert condition or user id = X Hasura User Id, which we can pass to Hasura from Auth0 using a rule.
[4:08] Add another rule to Auth0 called JWT claims, and copy the sample function from the repo. This will add a few claims like the role as user, and the user ID to the JWT that Hasura can use. Save the Auth0 rule and save the permission back in Hasura. Then, add the same check for the update permission.
[4:44] With that setup, your app also has authorization for data configured. We can query public data like playlists without being authenticated, but need to be logged-in for more sensitive data. Otherwise, we'll get validation errors.