> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth-scopes.md).

# OAuth Scopes

Reference for Veza OAuth2 scopes used by OAuth2 Clients and OAuth2 Apps.

This reference lists the OAuth2 scopes available in Veza for API and programmatic access. Scopes define the set of operations an access token can perform. Administrators select scopes when issuing credentials for OAuth2 Clients and OAuth2 Apps.

* [Overview](#overview)
* [Scope naming convention](#scope-naming-convention)
* [Standard scopes](#standard-scopes)
* [Public-role scopes](#public-role-scopes)
* [Feature-gated scopes](#feature-gated-scopes)
* [Grant types](#grant-types)
* [Related documentation](#related-documentation)

### Overview

Veza issues OAuth2 access tokens to authenticate API requests. Each token carries one or more scopes that restrict what the holder can do. Administrators choose scopes when:

* Creating an [OAuth2 Client](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-clients.md) for machine-to-machine access, using either the client credentials grant or the JWT bearer grant.
* Creating an [OAuth2 App](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-apps.md) that acts on behalf of a user, using the authorization code grant.

Some scopes correspond directly to a Veza role (see [Public-role scopes](#public-role-scopes)); others target a specific module or feature and follow the naming convention described below.

### Scope naming convention

Veza uses two scope formats:

* **Module scopes** follow the pattern `<module>:<resource>:<permission>`. For example, `lcm:access-requests:manage` grants management of access requests inside the Lifecycle Management module. New scopes added to the platform follow this pattern.
* **Public-role scopes** use a Veza role slug directly, such as `viewer` or `oaa_push`.

### Standard scopes

Standard scopes are available across the platform without additional configuration.

| Scope                        | Description                                                                                                                        | Grant types                                        |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| `profile`                    | Retrieve basic profile information (name, email).                                                                                  | Authorization code                                 |
| `lcm:access-requests:manage` | Manage Lifecycle Management access requests, including approving, rejecting, assigning approvers, and managing watchers.           | Authorization code                                 |
| `servicenow:aict:read`       | Read assessment risks and queries from Veza for ServiceNow AICT. Includes `assessments:queries:read` and `assessments:risks:read`. | Authorization code, client credentials, JWT bearer |
| `assessments:queries:read`   | Read assessment queries and query results.                                                                                         | Authorization code, client credentials, JWT bearer |
| `assessments:risks:read`     | Read assessment risks.                                                                                                             | Authorization code, client credentials, JWT bearer |

#### OpenID Connect scopes

`profile` is the only OpenID Connect scope Veza accepts. A token that carries `profile` can read the authenticated user's profile claims from the UserInfo endpoint. See [Get user information](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-apps.md#get-user-information).

Because `profile` identifies a person, only the authorization code flow can request it. A machine-to-machine token acts as a service account rather than a person, so the client credentials and JWT bearer grants reject it.

Veza rejects `openid`, `email`, and `offline_access` in every flow:

* Veza does not issue ID tokens and does not publish an OpenID Connect discovery document, so `openid` has no effect.
* `profile` already returns the email claim, so `email` adds nothing.
* The authorization code flow issues a refresh token without `offline_access`.

Adding any of the three to a client's scope list fails validation, and an authorization request that includes one fails with an `invalid_request` error. If your OAuth2 library requests `openid` by default, configure it to send only the scopes listed on this page.

### Public-role scopes

Public-role scopes mirror selected Veza roles and grant the capabilities of that role. See [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md) for the full description of each role.

| Scope              | Corresponding role                                                                                                   | Description                                                                                       | Grant types                    |
| ------------------ | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------ |
| `oaa_push`         | [OAA Push](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md#early-access-roles)                    | Upload Open Authorization API (OAA) payloads. Used by team service accounts and OAA integrations. | Client credentials, JWT bearer |
| `viewer`           | [Viewer](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md#early-access-roles)                      | Read-only access to Veza features such as Search and Dashboards.                                  | Client credentials, JWT bearer |
| `provider_manager` | [Integrations Manager](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md#generally-available-roles) | Connect and edit integrations and data sources.                                                   | Client credentials, JWT bearer |
| `auditor`          | [Auditor](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md#early-access-roles)                     | Export audit logs and events.                                                                     | Client credentials, JWT bearer |

### Feature-gated scopes

The following scopes appear only when the corresponding feature is enabled on your tenant. Contact Veza support to request enablement.

{% hint style="warning" %}
The ServiceNow sign-in, ServiceNow SIR, and assessment VQL scopes are pre-release. They are listed here for reference and are subject to change before general availability.
{% endhint %}

| Scope                            | Description                                                                                                                                | Grant types                                        |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------- |
| `pipeline:insight-point:operate` | Operate the Insight Point pipeline, including data ingestion, discovery, and extraction.                                                   | Client credentials, JWT bearer                     |
| `servicenow:auth:sign-in`        | Enable sign-in from ServiceNow to Veza.                                                                                                    | JWT bearer                                         |
| `servicenow:sir:read`            | Render the Veza Access Graph in ServiceNow SIR. Includes `assessments:queries:read`, `assessments:risks:read`, and `assessments:vql:read`. | Authorization code, client credentials, JWT bearer |
| `assessments:vql:read`           | Read assessment VQL query results.                                                                                                         | Authorization code, client credentials, JWT bearer |

Veza Support enables the Insight Point scope with OAuth 2.0 for Insight Points, and the ServiceNow sign-in, ServiceNow SIR, and assessment VQL scopes with the ServiceNow-to-Veza integration.

### Scope dependencies

Some scopes include other scopes. A client or app granted a scope can also call the endpoints its included scopes allow, so you don't need to add them separately. For example, `servicenow:aict:read` includes `assessments:queries:read` and `assessments:risks:read`. When you select a scope in the **Allowed scopes** list, the scopes it includes are selected too, and the **Effective scopes** list shows the full set.

### Grant types

The grant type is determined by the credential that requests the token. Each scope is available to a specific set of grant types, listed in the tables above.

* **Authorization code** is the interactive flow. A user signs in and consents on a Veza screen, and the resulting token acts on that user's behalf. Configure this flow with an [OAuth2 App](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-apps.md).
* **Client credentials** and **JWT bearer** are the machine-to-machine flows. No user is involved: the token acts as a service account bound to a Veza team. Configure either flow with an [OAuth2 Client](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-clients.md).

Scopes available to the machine-to-machine flows support both client credentials and JWT bearer, so a scope you can use with one is available with the other. The exception is `servicenow:auth:sign-in`, which supports JWT bearer only.

### Related documentation

* [User Roles and Permissions](/4yItIzMvkpAvMVFAamTf/administration/administration/users/roles.md): the role definitions referenced by public-role scopes.
* [OAuth2 Clients](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-clients.md): configure machine-to-machine OAuth2 clients for API access.
* [OAuth2 Apps](/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth2-apps.md): configure applications that access Veza on behalf of a user.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/authentication/oauth-scopes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.