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

# Authentication options

> How users authenticate to the hosted Web UI (Okta-managed vs Federated SSO).

The Web UI supports two ways to authenticate users:

1. **Resistant AI-managed accounts (Okta-managed)**
2. **Federated SSO** via your Identity Provider (**SAML 2.0** or **OIDC**)

<Note>
  Web UI authentication is for human users in the UI and is separate from Documents API authentication.
</Note>

## How to choose

* Choose **Okta-managed** for the fastest setup, smaller teams, PoCs, or when you don’t require federated identity.
* Choose **Federated SSO** if you need enterprise governance (MFA, conditional access, automated offboarding, auditability).

## Option 1 — Resistant AI-managed accounts (local password)

This is the simplest setup when you want Resistant AI to manage user accounts directly using email and password authentication.

**How it works**

* Resistant AI provisions the first Admin user during onboarding
* Admin users invite additional team members via the Web UI
* Users complete an invitation/activation flow and set their password
* Users sign in with their email and password

**Best for**

* Smaller teams
* PoCs and early-stage deployments
* Customers without a strong preference for federated identity

**What you need to provide**

* Email address and name for the first Admin user
* Which stage(s): Testing and/or Production

<Tip>
  Once the first Admin is provisioned, they can invite and manage users directly in the Web UI without involving Support. See [Admin settings (local password users)](./local-user-admin) for details.
</Tip>

## Option 2 — Federated SSO (recommended for enterprise)

Federated SSO allows users to authenticate with your existing corporate IdP and policies.

**Supported standards**

* **SAML 2.0** (most common for enterprise)
* **OIDC** (where applicable)

**Best for**

* Enterprise IAM governance
* Centralized MFA and conditional access
* Automated joiner/mover/leaver processes

**What you need to provide**

* IdP metadata / configuration details required for setup
* Attribute mapping (at minimum: email, first name, last name)
* Optional: role assignment mapping rules (e.g., read-only vs read-write)

<Tip>
  Deep links work as long as the user is authenticated and has access to the tenant. If not, they will be redirected to your IdP / login and then returned.
</Tip>

## Roles (high level)

* **Read-only**: view results
* **Read-write**: submit documents and view results

## Testing environment caveat

Testing and production are separate environments.

* Users must be assigned/provisioned for the **testing tenant/app** specifically
* Federated SSO is typically configured separately for testing vs production tenants

## Next steps

* [Admin settings (local password users)](./local-user-admin) — manage users with password authentication
* [Admin settings (SSO-managed tenants)](./sso-admin-settings) — view users with SSO authentication
* [SSO setup (SAML 2.0)](./sso-saml) — configure SAML SSO
* [SSO setup (OIDC)](./sso-oidc) — configure OIDC SSO
* [Microsoft Entra ID (SAML 2.0)](./sso-entra-id) — specific guidance for Entra ID