> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/authentication-and-authorization.md).

# Authentication & Authorization

Authentication and authorization work together, but they answer different questions.

**Authentication** answers: who is this user or application?

**Authorization** answers: what is this identity allowed to do?

DataOS authenticates users through the customer’s Identity Provider (IdP), so users can access DataOS with their enterprise identity. After identity is established, DataOS evaluates access through Instance roles, Tenant roles, Resource permissions, grants, and policies.

This page explains how DataOS connects to an IdP, how IdP groups map to Instance-level roles, and how authorization is evaluated inside DataOS. After this, read [Access control](/operate/v1/access-control.md) to understand the complete model for roles, permissions, grants, policies, and Resource-level access.

## How authentication works

DataOS uses **OpenID Connect (OIDC)** for authentication and supports Single Sign-On (SSO) through enterprise identity providers.

DataOS connects to identity systems in one of two ways:

* **OIDC-native IdPs:** Identity providers such as Microsoft Entra ID and Keycloak connect to DataOS through the standard OIDC flow.
* **Non-OIDC identity systems:** LDAP- or SAML-based systems connect through **Dex**, which acts as a federated OIDC provider. Dex translates the identity response into a DataOS-compatible token.

Applications and APIs authenticate differently. They must use a [DataOS API Token](https://v2.dataos.info/references/key-concepts/api-tokens).

{% hint style="info" %}
Applications that call DataOS APIs must use a DataOS API Token. Tokens issued directly by the enterprise IdP cannot be used.
{% endhint %}

As part of the IdP configuration, the customer also defines which IdP groups DataOS should use for Instance-level access. These group memberships are sent to DataOS as identity claims and mapped to DataOS Instance roles.

## IdP group mapping to Instance roles

IdP group mapping controls only Instance-level access. It does not assign Tenant roles or Resource permissions.

* **User:** Allows the user to access DataOS without Instance-level administrative privileges.
* **Operator:** Allows the user to operate and administer the DataOS Instance.

All other Tenant-level roles are managed inside DataOS at the Tenant level.

Tenant Admins assign Tenant roles after the user identity exists in DataOS. Resource permissions, grants, and governed data policies are also managed inside DataOS.

## How authorization works

After identity is established, DataOS evaluates what the user is allowed to do. Authorization is evaluated in the correct Tenant context and follows the DataOS access model:

* **Instance roles**, such as `User` and `Operator`
* **Tenant roles**, such as `Tenant Admin`, `Data Admin`, `Data Developer`, and `Data Consumer`
* **Resource permissions**, such as `Can Use`, `Can Edit`, and `Can Manage Access`
* **Grants**, including explicit grants such as `RunAsUser`
* **Policies**, including governed data policies such as masking and row filters

A role at one level does not automatically grant access at every other level. For example, a Tenant role defines what the user can do inside that Tenant, but Resource permissions and governed data policies are still evaluated separately.

For governed data access, semantic-layer policies are applied at query time based on the requesting identity. If the required access is not present, the request is denied.

## Relationship to the access model

Authentication establishes the identity. Authorization evaluates what that identity can do.

A successful sign-in does not automatically grant access to Tenants, Resources, Data Products, applications, workloads, or governed data. Access is assigned and evaluated through the DataOS access model.

For the complete model, including roles, permissions, grants, policies, Resource dependencies, and `runAsUser`, see [Access control](/operate/v1/access-control.md).


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/operate/v1/authentication-and-authorization.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.