Identity providers (SSO)

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 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

1 2	`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) or set up auto-share membership from group claims.

What's next#

SCIM provisioning — automate user create/update/delete.
Audit and activity — see who signed in when.