Okta 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 Okta Admin Console

Okta Admin Console → Applications → Create App Integration → OIDC, OpenID Connect → 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 Okta.

Assignments: Assign the app to the Okta groups (or people) who should get Bolt. An unassigned user cannot sign in at all.
Copy the values Bolt needs: Client ID, Client secret, and domain acme.okta.com.

That is the whole IdP side. Bolt never calls back into Okta with an admin token, and nothing is written into your directory. Issuer resolved by Bolt: https://<your-okta-org-domain> (the org authorization server).

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 Okta, 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=okta
APP__PLATFORM__IDENTITY__DOMAIN=acme.okta.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

Using a custom authorization server (/oauth2/default) rather than the org server? Set PROVIDER=generic-oidc and DISCOVERY_URL=https://acme.okta.com/oauth2/default in place of DOMAIN.

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.

Okta 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	Okta → Bolt app → Assignments	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	Okta → Bolt app → Provisioning (SCIM 2.0) Base URL `https://bolt.<domain>/scim/v2`	Push Users and Push Groups. Deactivating in Okta 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.

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