2020-01-14 15:57:45 +03:00
.. meta ::
2020-02-27 13:13:07 +03:00
:description: Manage GraphQL Authentication and Authorization with Hasura
2020-01-14 15:57:45 +03:00
:keywords: hasura, docs, authentication, auth, authorization
2020-03-11 22:42:36 +03:00
.. _auth:
2020-03-02 14:24:19 +03:00
Authentication & Authorization
==============================
2018-09-11 14:11:24 +03:00
2018-12-03 15:12:24 +03:00
.. contents :: Table of contents
:backlinks: none
:depth: 1
:local:
2019-05-17 15:03:35 +03:00
In Hasura, access control or authorization is based on **roles** . Let's take a look at how this works
2019-09-11 10:17:14 +03:00
when the GraphQL engine receives a request:
2018-09-11 14:11:24 +03:00
2020-08-25 19:21:21 +03:00
.. thumbnail :: /img/graphql/core/auth/auth-high-level-overview.png
2020-01-08 16:20:18 +03:00
:alt: Authentication and authorization with Hasura
2018-09-11 14:11:24 +03:00
2019-05-17 15:03:35 +03:00
As you can see from this:
2018-09-11 14:11:24 +03:00
2020-06-24 20:30:08 +03:00
- **Authentication** is handled outside of Hasura. Hasura delegates authentication and resolution of request
2019-05-17 15:03:35 +03:00
headers into session variables to your authentication service *(existing or new)* .
2018-09-11 14:11:24 +03:00
2019-05-17 15:03:35 +03:00
Your authentication service is required to pass a user's **role** information in the form of session
variables like `` X-Hasura-Role `` , etc. More often than not, you'll also need to pass user information
2019-09-11 10:17:14 +03:00
for your access control use cases, like `` X-Hasura-User-Id `` , to build permission rules.
2019-01-15 13:49:58 +03:00
2019-05-17 15:03:35 +03:00
- For **Authorization** or **Access Control** , Hasura helps you define granular role-based access control
rules for every field in your GraphQL schema *(granular enough to control access to any row or
column in your database)*.
2018-09-11 14:11:24 +03:00
2020-06-24 20:30:08 +03:00
Hasura uses the role/user information in the session variables and the actual request itself to validate
the request against the rules defined by you. If the request/operation is allowed, it generates an SQL
2019-05-17 15:03:35 +03:00
query, which includes the row/column-level constraints from the access control rules, and sends it to
the database to perform the required operation (*fetch the required rows for queries, insert/edit
rows for mutations, etc.*).
2018-09-11 14:11:24 +03:00
2019-05-17 15:03:35 +03:00
**See more details about setting up authentication and access control at:**
2018-09-11 14:11:24 +03:00
.. toctree ::
2019-05-17 15:03:35 +03:00
:maxdepth: 1
authentication/index
authorization/index
2020-07-22 00:44:20 +03:00
.. admonition :: Learn course
If you'd like to learn about authentication and authorization / access control by following a tutorial, check out our Learn course, `Authentication with Hasura <https://hasura.io/learn/graphql/hasura-auth-slack/introduction/> `__ .