Skip to content
Developer Edition runs on one host and does not require a product license file. Need multi-host deployment or performance testing at scale? Explore Enterprise Edition

Authorization overview

Authorization determines whether a user can connect to a service group and which operations the user can perform on its resources. After creating the user, follow Configure user access to invite the user and grant privileges.

Requirements for accessing a service group

For password-authenticated connections and resource access, the user must meet these requirements:

Requirement Description
The account exists and can be used The user is enabled and is not locked. For more information, see User management.
The user has joined the service group A user with ADMIN invites the user by using INVITE USER.
The user has CONNECT This privilege allows the user to connect to the service group.
The user can access the schema Access to a non-default schema requires USAGE.
The user can perform the required operation For example, querying a graph requires MATCH. Writing data can require INSERT, UPDATE, or DELETE.

These requirements are independent. For example, INVITE USER does not grant CONNECT, and CONNECT does not grant access to a schema or graph. For the complete procedure, see Configure user access.

Privileges and their sources

A privilege allows an action on a resource. For example, MATCH on graph /finance/transactions allows a user to query that graph.

An owner is the user responsible for managing a service group or resource. A user's privileges can come from the following sources:

  • Privileges granted directly to the user.
  • Privileges in roles granted to the user.
  • The built-in ADMIN role automatically held by the service group owner.
  • Privileges provided by resource ownership.
  • Privileges provided by the system, such as USAGE on /default_schema.

Privileges from all sources are combined. If the same privilege comes from several sources, the user can still perform the operation as long as one source remains.

Direct grants and roles

  • A direct grant applies to one user. Use it for temporary or special access needs.
  • A role is a reusable set of privileges. Use roles when multiple users have the same responsibilities.

A user can have up to 16 custom roles. A role cannot be granted to another role. For instructions, see Manage roles and privileges.

The ADMIN role

Each service group has one owner. The owner holds the built-in ADMIN role and can manage users, roles, privileges, and resources in that service group.

You cannot grant or revoke ADMIN by using GRANT ROLE or REVOKE ROLE.

Resource ownership

Resource ownership permits management of the owned resource without an explicit grant. Schemas, graph types, graphs, user-defined procedures (UDPs), and user-defined functions (UDFs) have owners.

Ownership of a resource in a non-default schema does not provide access to the schema. The owner still needs USAGE on the schema. To view or change an owner, see SHOW OBJECTS and ALTER OWNER.

Scope of privileges on parent resources

Some privileges on a schema also apply to resources in that schema. For example, MATCH ANY GRAPH on /finance allows the user to query every graph in /finance.

Schema USAGE is separate from privileges on resources in the schema. A user needs both USAGE and the privilege required for the operation. For a complete list, see Privilege reference.

Authorization methods

Scenario Recommended method
Multiple users have the same responsibilities Grant privileges to a role, and then grant the role to the users.
One user needs temporary or special access Grant privileges directly to the user.
A user needs to manage the entire service group Change the service group owner.
A user needs to manage a specific resource Grant the required privileges. For a resource type that supports ownership changes, you can also transfer ownership to the user.

When changes take effect

  • CONNECT is checked when a user starts a new session. Revoking CONNECT does not end an existing session. To end it immediately, use KILL SESSION.
  • Other privilege changes take effect after they are synchronized to the Graph services. To verify the result, reconnect as the target user and perform the expected operation.

Task guides

Goal Recommended page
Give a user access for the first time Configure user access
Control access to a non-default schema Schema access control
Reuse the same privileges for multiple users Manage roles and privileges
Find which actions a resource supports Privilege reference