Single Sign-On (SSO)

superglue supports Okta sign-in through OpenID Connect (OIDC). Optional SCIM provisioning creates users, synchronizes groups, and deactivates access during offboarding.

!

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

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.
• An Okta SCIM 2.0 integration when you need lifecycle management.

Configure Okta

1. In Applications → Applications, create an OIDC - OpenID Connect integration with Web Application as its type.
2. Enable the Authorization Code grant and client-secret authentication. superglue also uses PKCE for the authorization flow.
3. Add https://<your-superglue-domain>/api/auth/oauth2/callback/okta as a sign-in redirect URI.
4. Assign the users or groups that should be able to sign in.
5. 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.

Add the role claim

Use a custom Okta authorization server so the role claim is included in the ID token issued during the authorization-code flow.

1. Configure the claim as an ID Token claim.
2. Include it Always.
3. 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.

Use a group-based role rule

For a group-based rule, create a superglue-admins group and use this claim expression:

isMemberOfGroupName("superglue-admins") ? 'admin' : 'member'

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
OKTA_SCIM_TOKEN	Optional SCIM bearer token copied into the provisioning integration
AUTH_DISABLE_SIGNUP	Required boolean controlling non-Okta self-service registration
AUTH_DISABLE_INVITES	Required boolean controlling organization invitations

Both account-creation flags must be set explicitly.

Configure an SSO-only deployment

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

Configure SCIM provisioning

Create the SCIM token

Set OKTA_ORG_ID, then run this command in Bash. It supports macOS, Linux, Git Bash, and WSL:

: "${OKTA_ORG_ID:?Set OKTA_ORG_ID first}"
od -An -N32 -tx1 /dev/urandom | tr -d ' \n'
printf '\n'

1. Store the opaque output as the OKTA_SCIM_TOKEN secret value.
2. Copy the same value into Okta.
3. Restart superglue after changing the value.

Configure the Okta SCIM integration

Configure an Okta SCIM 2.0 integration with these values:

Setting	Value
Base URL	https://<your-superglue-domain>/api/auth/scim/v2
Authentication	HTTP Header / bearer token
API token	The configured OKTA_SCIM_TOKEN value
Unique field	userName, using the user’s primary email address

Then, in Okta:

1. Enable Create Users, Update User Attributes, and Deactivate Users.
2. Assign the same users or groups to the OIDC and SCIM integrations.

!

A SCIM-created user starts with the member base role. On sign-in, the signed userType or user_type claim can synchronize that role to admin.

Synchronize Okta groups

1. Enable Push Groups in the Okta provisioning settings.
2. Add each Okta group that must control superglue access.

Each pushed Okta group creates one custom role with the same name. Open Access Rules in superglue to configure that role’s resource grants.

Okta controls the role’s users. superglue controls the role’s grants.

Group updates have these effects:

• Adding or removing an Okta group member updates the custom role assignment.
• Renaming an Okta group renames the custom role and preserves its grants.
• Deleting a pushed Okta group deletes its custom role, assignments, and grants.

Group sync does not change the admin or member base role. The signed userType or user_type claim continues to control that role.

Okta group names must be unique in superglue. They cannot use the reserved names admin or member. Rename an existing custom role before pushing an Okta group with the same name.

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 when SCIM has not created it already.
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.

Deprovisioning

When Okta deactivates an assigned user, it sends the SCIM state active: false. superglue then:

1. Removes the user from the organization specified by OKTA_ORG_ID, with their role assignments.
2. Disables the user’s API keys and schedules in that organization.
3. When the user belongs to no other organization, bans the account and deletes all sessions and MCP OAuth grants. Otherwise it deletes only the sessions for that organization.

FAQ

Can I set both account-creation flags to true?

Yes, when Okta is configured. 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.

Do custom authorization servers need an extra Okta product?

Custom authorization servers may require Okta API Access Management in production.

Can existing users sign in with Okta?

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

What happens when I reactivate a user in Okta?

Reactivating the user in Okta restores login access and adds the user back to the organization with the member base role. It does not re-enable API keys or schedules. Review and enable those resources manually after reactivation.