> ## Documentation Index
> Fetch the complete documentation index at: https://docs.siderolabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication and Authorization

> Understand how Omni handles user authentication, identity providers, roles, and automation.

Omni integrates with several identity providers to authenticate users securely. This page provides an overview of supported authentication methods and how they affect user and role management.

To configure an authentication provider for a self-hosted deployment, see [Omni Configuration Examples](../reference/omni-configuration).

## Auth0

Omni supports authentication via Auth0.

### GitHub

When logging in with GitHub, you must use your primary, verified email address.

## OIDC

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. It provides user authentication and basic profile information for web and mobile applications. Omni [can be configured to use OIDC providers](../self-hosted/run-omni-on-prem#oidc) to authenticate users.

## SAML

Security Assertion Markup Language (SAML) is an open standard that enables identity providers (IdPs) to pass authentication and authorization information to service providers (SPs). In this workflow, Omni acts as the service provider.

To enable SAML for your account, please submit a ticket through [Zendesk](https://sidero.zendesk.com/).

Using SAML changes how user identities are managed in Omni:

* Users are created automatically on their first login to Omni.
  * The first user created is assigned the `Admin` role.
  * All subsequent users are assigned the `None` role.
* An `Admin` can modify the roles of other users.
* User creation and removal must be performed in the IdP — not in Omni.
* Attributes from the SAML assertion are added to the user’s `Identity` resource with the prefix `saml.omni.sidero.dev/`.
* Access Control Lists (ACLs) can be used to grant fine-grained permissions beyond roles.

## Authentication for automation

In addition to interactive login, `omnictl` can also be used in automation. When using user authentication in non-interactive workflows, Omni issues short-lived credentials that expire after a limited time. User tokens can remain valid for up to eight hours, and Omni-generated user public keys currently expire after four hours. These limits are not configurable.

Because of this, long-running automation or CI/CD pipelines that rely on user authentication may fail when credentials expire. To ensure uninterrupted access for automation, scripts, and other non-interactive use cases, we recommend using Omni Service Accounts instead of user authentication.