Enterprise Feature - SSO is available on superglue Enterprise plans. Contact
us to learn more.
- A provider button (e.g. Okta or Microsoft) appears on the login page.
- Users are provisioned just-in-time — their superglue account is created on first login, with
no manual invitation step.
- Each user is placed directly into your shared organization with a base role (Admin or
Member) derived from a claim in their ID token.
- Roles are re-synced on every login, so changes in your identity provider take effect the next
time the user signs in.
How role assignment works
superglue reads a base-role claim from the ID token and maps it directly to a superglue base role:
| Claim value | superglue base role |
|---|
admin | Admin |
member | Member |
| anything else / missing | Access denied |
- Okta sends this as a
userType claim (both userType and user_type claim names are
accepted).
- Entra ID sends this via an app role (
roles claim) or an optional claim — see the Entra
section below.
Okta
Configuration
1. Create the Okta application
In the Okta admin console, create an OIDC - Web Application:
- Sign-in redirect URI:
https://<your-superglue-domain>/api/auth/oauth2/callback/okta
- Grant type: Authorization Code (PKCE is used automatically)
Note the Client ID and Client Secret.
2. Send the userType claim
superglue derives the base role from the ID token, so Okta must include the claim:
- Go to Applications → your app → Sign On tab.
- Under OpenID Connect ID Token, click Edit.
- Add a claim:
- Name:
userType
- Include in token type: ID Token, Always
- Value: map it to the Okta attribute that holds
admin / member for each user (for
example a custom user profile attribute, or a group-based expression).
- Save.
The claim must be present in the ID token — superglue verifies and decodes the ID token JWT
directly. A claim that only appears in the access token or the userinfo endpoint will not be read.
3. Set environment variables
| Variable | Required | Description |
|---|
OKTA_CLIENT_ID | Yes | OIDC application client ID. Presence of all three OKTA_* values enables the Okta button. |
OKTA_CLIENT_SECRET | Yes | OIDC application client secret. |
OKTA_ISSUER | Yes | Your Okta org URL, e.g. https://your-domain.okta.com (the Org Authorization Server). |
OKTA_ORG_ID | Yes | The superglue organization ID all Okta users are placed into. |
AUTH_EXCLUSIVE_PROVIDER | No | Set to okta to hide email/Google/GitHub and show only the Okta button (see below). |
Microsoft Entra ID
Microsoft Entra ID (formerly Azure Active Directory) is supported through the same OIDC flow as
Okta.
How role assignment works (Entra)
Entra ID does not have a built-in userType token claim like Okta. Instead, the base role is driven
by an app role assignment that surfaces in the roles claim of the ID token:
roles claim contains | superglue base role |
|---|
admin | Admin |
member | Member |
| neither / missing | Access denied |
roles claim is empty or absent, the login is
denied.
Configuration
1. Register the application
In the Entra admin center → App registrations → New
registration:
- Supported account types: choose single-tenant (your directory only) unless you need guests.
- Redirect URI (type Web):
https://<your-superglue-domain>/api/auth/oauth2/callback/entra
From the app’s Overview, note the Application (client) ID and the Directory (tenant) ID.
Under Certificates & secrets, create a client secret and note its value.
2. Define and assign app roles
- Go to App roles → Create app role.
- Create two roles with these Values (the value is what lands in the token, not the display
name):
adminmember- Allowed member types: Users/Groups.
- Go to Enterprise applications → your app → Users and groups and assign each user (or a
group) to either the
admin or member app role.
The assigned role’s Value is emitted in the roles claim of the ID token.
The claim must be present in the ID token — superglue verifies and decodes the ID token JWT
directly. App-role values flow into the ID token automatically once roles are assigned.
3. Set environment variables
| Variable | Required | Description |
|---|
ENTRA_CLIENT_ID | Yes | Application (client) ID. Presence of all required ENTRA_* values enables the Microsoft button. |
ENTRA_CLIENT_SECRET | Yes | Client secret value. |
ENTRA_TENANT_ID | Yes | Directory (tenant) ID. The issuer is derived as https://login.microsoftonline.com/<tenant>/v2.0. |
ENTRA_ORG_ID | Yes | The superglue organization ID all Entra users are placed into. |
AUTH_EXCLUSIVE_PROVIDER | No | Set to entra to hide email/Google/GitHub and show only the Microsoft button (see below). |
Shared behavior
The following applies to both Okta and Entra ID.
Make SSO the only login method
To require everyone to sign in through a single provider, set AUTH_EXCLUSIVE_PROVIDER to that
provider’s id:
AUTH_EXCLUSIVE_PROVIDER=okta # or: entra
?providers=all to the login URL
(https://<your-superglue-domain>/login?providers=all) — useful for break-glass access.
Provisioning details
- No personal organization. SSO-provisioned users are added straight to the configured org
(
OKTA_ORG_ID / ENTRA_ORG_ID). They do not get the personal org that email/Google/GitHub
signups receive.
- Signup-disabled bypass. Even when
NEXT_PUBLIC_DISABLE_SIGNUP=true, valid SSO logins are
provisioned — the disabled-signup gate only applies to other providers.
- Existing users are unaffected. Email, Google, and GitHub accounts continue to work exactly as
before. Enabling SSO only adds a login option.
Deprovisioning
When a user is deactivated in your identity provider, it stops issuing tokens for them, so they can
no longer sign in to superglue. Their existing superglue account and any active sessions are not
automatically revoked — remove the user from Control Panel → Organization if you need to
terminate access immediately.
