Auth0 SSO and Access Setup: IT Admin Guide

Name: Aeira
Brand: Sparcle

Bolt Enterprise · single sign-on, group provisioning and desktop rollout. Setup time is about 15 minutes.

SPARCLE
Bolt Enterprise
rev. 2026-10-20

1 · Create the application in Auth0 Dashboard

Auth0 Dashboard → Applications → Create Application → Regular Web Application.
Name it Bolt. Grant types: Authorization Code plus Refresh Token.
Sign-in redirect URI:
https://bolt.<yourdomain>/api/auth/callback
Sign-out redirect URI: https://bolt.<yourdomain>/
Scopes: openid email profile offline_access. Bolt requests nothing else from Auth0.

Organizations, or a Rule/Action gate: Auth0 has no per-app assignment list by default. Gate access with an Organization, or with an Action that denies login outside an allowed group.
Copy the values Bolt needs: Client ID, Client secret, and domain acme.us.auth0.com.

That is the whole IdP side. Bolt never calls back into Auth0 with an admin token, and nothing is written into your directory. Issuer resolved by Bolt: https://<your-auth0-domain>.

2 · Give the credentials to Bolt

Nothing here is needed to try Bolt. For a pilot, people install the desktop app from sparcle.app/download and use it. This page is for when you want a shared deployment with single sign-on behind it, and the enterprise bundle referenced below is sent by Sparcle at that point.

A · Setup wizard (no file editing)

The installer and first-run admin wizard walk this step: pick Auth0, paste the values above, click through. Self-hosted installs can instead run enterprise/setup.sh, which writes a .env.prod for you.

B · Configuration file (self-hosted)

APP__PLATFORM__IDENTITY__PROVIDER=auth0
APP__PLATFORM__IDENTITY__DOMAIN=acme.us.auth0.com
APP__PLATFORM__IDENTITY__CLIENT_ID=<client-id>
APP__PLATFORM__IDENTITY__CLIENT_SECRET=<client-secret>
APP__PLATFORM__IDENTITY__REDIRECT_URI=\
  https://bolt.example.com/api/auth/callback

DOMAIN is your Auth0 tenant domain, including the region segment where you have one (for example acme.us.auth0.com).

C · SAML 2.0 (on the web)

SAML 2.0 sign-in works on the web, checked against your company's trusted certificates. On the desktop app, choosing SAML opens Bolt on the web, so keep the OIDC application above for desktop sign-in. These are the values the SAML app needs.

Auth0 field	Value
Single sign-on URL (ACS)	`https://bolt.<domain>/api/auth/saml/callback`
SP metadata	`https://bolt.<domain>/api/auth/saml/metadata`
Audience / Entity ID	as published in the SP metadata above
Attribute statement	`email` (required)

D · Verify

curl https://bolt.example.com/health  → {"status":"healthy", ...}

status is healthy, degraded or critical. Then sign in at https://bolt.<domain> with a corporate account. A failed login names its cause: redirect-URI mismatch, unassigned user, or clock skew.

3 · Granting access: four separate levers

Lever	Where you set it	What it controls
Who can sign in	Auth0 → Bolt app → Organizations, or a Rule/Action gate	The primary gate. Remove the assignment to revoke.
Who is a Bolt admin	Bolt Admin → assign roles, or map groups from the ID token `groups` claim (`allowed_groups`, `group_roles`), or list admins by email (`allowed_users`)	The admin console, audit log, policy and connector settings. Changes apply live, no restart.
Joiner, mover, leaver	Auth0 → Bolt app → Provisioning (SCIM 2.0) Base URL `https://bolt.<domain>/scim/v2`	Push Users and Push Groups. Deactivating in Auth0 deactivates in Bolt and ends all of that person's sessions and connected devices.
What data Bolt can read	Workspace and connector consent (section 4)	Which sources are reachable per user: Mail, Calendar, Drive, Confluence and so on.

SCIM token: issue it in Bolt (Admin → SCIM → New token). It is displayed once only, so paste it straight into the provisioning screen as the bearer token. Groups: To grant admin or other roles by group, add a groups claim to the ID token and map each group to a role in Bolt (group_roles, or allowed_groups for admin). Groups pushed over SCIM do not grant roles. SCIM keeps joiners and leavers in step.

4 · What Bolt is able to read

Read-only, always. Where Bolt reads mail, calendar or files it asks for gmail.readonly, calendar.readonly, drive.readonly, tasks.readonly and contacts.readonly. There is no write scope to grant.
One surface at a time. Signing in asks only for openid, email and profile. Each surface asks for its own permission when first opened, so a person can be signed in and reach nothing.
Each source's own permissions are enforced at retrieval, for any caller, including an MCP gateway. Confluence page restrictions that override space permissions, Drive sharing, and the equivalent elsewhere.

Auth0 signs people in. It does not carry their mail, calendar or files. Those live in Google Workspace or Microsoft 365, and connecting them is a separate step configured per deployment rather than something Auth0 grants. Tell us which one you run and we will confirm the wiring for your tenant before you plan around it.

5 · Rolling the desktop app onto laptops (pick one)

Method	Configuration	Notes
MDM (macOS) Jamf, Mosyle, Kandji	Payload `com.sparcle.bolt`: `EnterpriseApiUrl` = `https://bolt.<domain>`, `ForceManagedMode` = true	Recommended. Users never type a URL. Push your internal CA here too, if Bolt uses one.
Group Policy (Windows)	`HKLM\Software\Sparcle\Bolt`, with `EnterpriseApiUrl` and `ForceManagedMode = 1`	Same effect as MDM.
DNS SRV	`_bolt._tcp.<domain>. SRV 10 5 443 bolt.<domain>.`	No MDM required.
First-launch wizard	User pastes the endpoint once	Fine for a pilot.