Single Sign-On (SSO)

!

Enterprise feature — SSO is available for superglue Enterprise deployments. Contact us to discuss access.

superglue supports Okta through OpenID Connect (OIDC). Okta authenticates the user, while superglue creates the account on first sign-in, adds it to one configured organization, and synchronizes its base role from the signed ID token.

Before you begin

You need:

• An existing superglue organization and its organization ID.
• An Okta administrator who can create an OIDC application and token claim.
• A public superglue app URL that Okta can redirect users back to.
• A role rule that maps every assigned Okta user to either admin or member.

Configure Okta

1. Create an application: In Applications → Applications, create an OIDC - OpenID Connect integration with Web Application as its type.
2. Enable the flow: Enable the Authorization Code grant and client-secret authentication. superglue also uses PKCE for the authorization flow.
3. Register the callback: Add https://<your-superglue-domain>/api/auth/oauth2/callback/okta as a sign-in redirect URI.
4. Assign access: Assign the users or groups that should be able to sign in.
5. Add the role claim: Configure an ID-token claim named userType or user_type. It must always return exactly admin or member for every assigned user.

!

superglue rejects a login when the role claim is missing or has any other value. This protects the organization from users being provisioned without an explicit base role.

Use a custom Okta authorization server so the role claim is included in the ID token issued during the authorization-code flow. Configure the claim as an ID Token claim, include it Always, and derive its value from the user profile or group policy used by your organization. Then use that authorization server’s issuer for OKTA_ISSUER, for example:

https://your-domain.okta.com/oauth2/default

Okta’s custom-claim guide explains how to add and preview an ID-token claim. Custom authorization servers may require Okta API Access Management in production.

Configure superglue

Set the following deployment variables:

Variable	Value
AUTH_PROVIDERS	Include okta; use okta alone for an SSO-only login page
OKTA_CLIENT_ID	Client ID from the Okta application
OKTA_CLIENT_SECRET	Client secret from the Okta application
OKTA_ISSUER	Exact issuer of the authorization server that adds the role claim
OKTA_ORG_ID	Existing superglue organization that receives provisioned users
AUTH_DISABLE_SIGNUP	Required boolean controlling non-Okta self-service registration
AUTH_DISABLE_INVITES	Required boolean controlling organization invitations

For an SSO-only deployment:

AUTH_PROVIDERS=okta
OKTA_CLIENT_ID=...
OKTA_CLIENT_SECRET=...
OKTA_ISSUER=https://your-domain.okta.com/oauth2/default
OKTA_ORG_ID=...
AUTH_DISABLE_SIGNUP=true
AUTH_DISABLE_INVITES=true

Both account-creation flags must be set explicitly. Setting both to true is valid when Okta is configured because Okta just-in-time provisioning remains available. The deployment rejects that combination when no Okta provider is configured, as it would leave no account-creation path.

Provisioning and role sync

On each successful Okta login, superglue:

1. Verifies the ID token against the configured issuer, client ID, and Okta signing keys.
2. Requires the email claim and a valid userType or user_type role claim.
3. Creates the superglue account on first login without requiring an invitation.
4. Adds or updates membership in the organization specified by OKTA_ORG_ID.
5. Assigns the admin or member base role from the token claim.

Existing users can also sign in with Okta. Other login methods remain available only when they are listed in AUTH_PROVIDERS.

Deprovisioning

The current integration provides just-in-time provisioning and role synchronization, not SCIM deprovisioning or Okta-driven session revocation.

Deactivating a user in Okta prevents future Okta sign-ins, but an existing superglue session is not revoked automatically. To terminate access immediately, remove the user’s organization membership in Control Panel → Organization. Reassign or disable any schedules, API keys, or other resources owned by that user as part of the same offboarding process.