---
title: Identity providers (SSO)
path: administration/identity-providers
status: published
---

ScaiDrive doesn't manage passwords. Users authenticate against your existing identity provider; ScaiDrive consumes the OIDC token. The supported transport is **OpenID Connect (OIDC)**, which works with every modern IdP — Okta, Entra ID (Azure AD), Google Workspace, Auth0, Keycloak, and ScaiKey itself.

Some legacy environments also need **SAML 2.0** or **LDAP** — both are supported, with caveats noted below.

## OIDC (recommended)

Identity → Identity Providers → **New provider** → **OIDC**.

You'll need from your IdP:

| Field | Where to get it |
|---|---|
| Issuer URL | IdP's discovery doc location, e.g. `https://login.example.com/` |
| Client ID | Issued when you register the ScaiDrive app in your IdP |
| Client secret | Same |
| Redirect URI | ScaiDrive will tell you — register it in your IdP first |
| Scopes | `openid profile email` minimum; add `groups` if you want group claims |

Click **Test connection** before saving — ScaiDrive will fetch the discovery doc and try a dry-run authorization. Common failure: the redirect URI in your IdP doesn't exactly match the one ScaiDrive expects (including trailing slash).

### Claim mapping

ScaiDrive expects three claims from the OIDC token by default:

| ScaiDrive field | OIDC claim |
|---|---|
| User identifier | `sub` |
| Email | `email` |
| Display name | `name` (falls back to `preferred_username`) |

If your IdP uses different claim names, override them in the **Claim mapping** section of the provider config.

### Group claims

If your IdP includes a `groups` claim in the token, ScaiDrive can auto-assign users to ScaiDrive groups with matching slugs. Enable in the provider config → **Auto-create groups from claim**. You'll typically want to also push group membership via [SCIM](/docs/scaidrive/administration/scim-provisioning) for reliability.

### Roles via claims

To assign admin role automatically based on an IdP claim, set **Role claim** to a claim name (e.g., `roles`) and a mapping:

```text
admin       ← if "drive-admin"      appears in the claim
superadmin  ← if "drive-superadmin" appears in the claim
```

User role gets re-evaluated on every sign-in. Removing the admin entitlement in your IdP demotes the user on their next sign-in (or immediately if you also revoke their sessions).

## SAML 2.0

Supported for environments where OIDC isn't available. Identity → Identity Providers → **New provider** → **SAML**.

ScaiDrive exposes its SP metadata at `/auth/saml/<provider-slug>/metadata`. Upload to your IdP, then paste the IdP's metadata XML into the **IdP metadata** field. Default attribute mappings:

- `NameID` → user identifier
- `emailAddress` → email
- `displayName` → display name

SAML group claims work similarly to OIDC's `groups` — match by group slug.

**Caveats:** ScaiDrive does not support SAML SLO (Single Log-Out) — signing out of ScaiDrive doesn't sign you out of the IdP. Most environments don't need this.

## LDAP

For air-gapped environments without an SSO server. Identity → Identity Providers → **New provider** → **LDAP**.

Supply:

- **Bind URL** — `ldaps://ldap.example.com:636`
- **Bind DN + password** — service account for searching
- **User base DN + filter** — where to find users
- **Group base DN + filter** — where to find groups (optional)
- **Attribute mappings** — same fields as OIDC

ScaiDrive authenticates by binding as the user with their password (so the password traverses ScaiDrive, briefly — *use LDAPS, never LDAP*).

**Caveats:** LDAP doesn't support MFA without an external broker; we strongly recommend you stand up Keycloak or ScaiKey in front of LDAP and have ScaiDrive talk OIDC to the broker.

## Multiple providers

You can register more than one IdP — useful if you have employees on one IdP and contractors on another. Each IdP gets its own sign-in button on the ScaiDrive login page; you can re-order or hide buttons in the provider config.

A user signed in through provider A and provider B in succession is matched as the *same* ScaiDrive user only if both IdPs return the same `sub` claim. Most orgs use a unique `sub` per IdP; in that case ScaiDrive treats them as two separate users (which is usually what you want).

## Disabling a provider

The provider list has an **Enabled** toggle. Disabled providers reject new sign-ins (existing sessions keep working until they expire) and disappear from the login page. Useful for temporarily blocking access from a specific IdP without deleting the config.

## Troubleshooting

- **"Discovery doc not reachable"** → IdP is on a private network ScaiDrive can't reach, or DNS is wrong.
- **"Invalid redirect URI"** → register the exact ScaiDrive callback URL (shown on the provider config page) in your IdP, including the scheme and any trailing slash.
- **User signs in but isn't a member of any share** → that's expected; SSO handles authentication, not authorization. Add them to a share (see [Users and groups](/docs/scaidrive/administration/users-and-groups)) or set up auto-share membership from group claims.

## What's next

- [SCIM provisioning](/docs/scaidrive/administration/scim-provisioning) — automate user create/update/delete.
- [Audit and activity](/docs/scaidrive/administration/audit-and-activity) — see who signed in when.