Does IssueBadge support SAML with Okta?

The Okta Integration Network listing uses OpenID Connect, not SAML. Both Okta-initiated sign-in (the tile on the End-User Dashboard) and IssueBadge-initiated sign-in (app.issuebadge.com/sso) use the same OIDC settings.

Is Okta single sign-on included on every IssueBadge plan?

Yes. Single sign-on and SCIM provisioning are included on every IssueBadge plan. Only the workspace owner can turn them on, under Settings, Single sign-on and provisioning.

What happens to a person's certificates when they are deactivated in Okta?

Nothing. Deactivating or unassigning someone in Okta deactivates their IssueBadge account but never deletes anything. Issued certificates, verification pages and audit history stay intact, and reactivating in Okta reactivates the account.

Can Okta deactivate the IssueBadge workspace owner?

No. Unassigning the owner returns a provisioning error and the owner keeps access, so a workspace can never lock itself out. Transfer ownership in IssueBadge first if the owner is leaving.

What should the Issuer URL be?

Your Okta org URL only, for example https://acme.okta.com, or your custom domain if the org uses one. Do not add /oauth2/default or any other path. Check the issuer first whenever Test sign-in fails or Okta shows a 400 Bad Request page.

Do existing IssueBadge team members lose their accounts when SSO is turned on?

No. Existing members are matched by email the first time they sign in through Okta, and provisioning links to an existing account with the same email rather than creating a duplicate.

How to set up IssueBadge in Okta: OIDC single sign-on and SCIM provisioning

1. Prerequisites

An IssueBadge workspace. You must sign in as the workspace owner: only the owner can open Settings → Single sign-on and provisioning. Single sign-on and provisioning are included on every IssueBadge plan.
An Okta org and an Okta administrator account with the Super Administrator or Application Administrator role.
For provisioning: the Okta Lifecycle Management feature must be enabled in your Okta org.
The email domain(s) of the people who will sign in, for example acme.com. IssueBadge only accepts single sign-on for the domains you list.
Every person must have a work email in Okta. IssueBadge uses the email address as the unique identifier (userName).

2. Supported features

The IssueBadge integration in the Okta Integration Network supports:

Feature	Supported	Notes
IdP-initiated SSO (OpenID Connect)	Yes	People click the IssueBadge tile on their Okta End-User Dashboard.
SP-initiated SSO (OpenID Connect)	Yes	People start at `https://app.issuebadge.com/sso` with their work email. See section 4.
Just-in-time (JIT) account creation	Yes	Optional. When "Create accounts on first sign-in" is on, an account is created the first time someone signs in through Okta.
Create users (SCIM 2.0)	Yes	Assigning a person or group in Okta creates the IssueBadge account. If an account with that email already exists in the workspace, Okta links to it.
Update user attributes (SCIM 2.0)	Yes	Changes to first name, last name and email in Okta are pushed to IssueBadge.
Deactivate users (SCIM 2.0)	Yes	Unassigning or deactivating in Okta deactivates the IssueBadge account. Reactivating in Okta reactivates it.
Push groups	No	Groups are used for assignment only. Roles are managed in IssueBadge.
Import users / profile sourcing	No	Okta is the source; IssueBadge does not push profile changes back.
Sync password	No	People sign in through Okta, so no password is stored for them in IssueBadge.

Limitations

Deactivation never deletes anything. Issued certificates, verification pages and audit history stay intact. A SCIM DELETE also deactivates rather than deletes.
The workspace owner cannot be deactivated through Okta. Unassigning the owner returns an error and the owner keeps access.
An email address can belong to only one IssueBadge workspace. Okta cannot move an existing account from another workspace into yours.
One Okta org per IssueBadge workspace.
New people receive the role you choose under "Role for new people" (Developer or Company admin). Owners can change roles later from Settings → Team.

3. Configuration steps

You will switch between the Okta Admin Console and the IssueBadge page Settings → Single sign-on and provisioning (app.issuebadge.com/settings/sso). Keep both open in separate tabs.

3.1 Add IssueBadge from the OIN catalog

In the Okta Admin Console go to Applications → Applications and click Browse App Catalog.
Search for IssueBadge and open the listing.
Click Add Integration.
On General Settings keep the application label IssueBadge (or rename it for your users) and click Done.

3.2 Copy the OIDC client credentials

Open the IssueBadge app you just added and select the Sign On tab.
Under Settings → Client Credentials (or OpenID Connect), copy the Client ID and the Client secret.
Note your Okta org URL, for example https://acme.okta.com. It is shown under your name in the top-right corner of the Admin Console. If your org uses a custom domain, use that domain instead.
Under Credentials Details, make sure Application username format is Email. IssueBadge matches people by email address.

The redirect URI (https://app.issuebadge.com/sso/callback) and the initiate-login URI (https://app.issuebadge.com/sso/start) are pre-configured in the OIN listing. You do not need to enter them.

3.3 Configure single sign-on in IssueBadge

Sign in to IssueBadge as the workspace owner and open Settings → Single sign-on and provisioning.
Under Identity provider choose Okta.
Issuer URL: paste your Okta org URL, for example https://acme.okta.com. Do not add /oauth2/default.
Client ID and Client secret: paste the values from step 3.2.
Email domains: enter the domains allowed to sign in with Okta, separated by commas, for example acme.com, acme.co.uk.
Role for new people: choose Developer (issue and manage credentials) or Company admin (also manages team and billing). This role is given to accounts created by sign-in or provisioning.
Leave Create accounts on first sign-in ticked if you want accounts created the first time someone signs in through Okta. Untick it if only provisioned or existing people may sign in.
Click Save changes.
Click Test sign-in. IssueBadge runs a real sign-in against Okta and reports the email that Okta returned. Fix any error before continuing.
Tick Single sign-on is on and click Save changes again.

Test with your own Okta account first, then a small pilot group, and only then the whole organisation. Existing IssueBadge team members keep their accounts; they are matched by email the first time they sign in through Okta.

3.4 Enable SCIM provisioning

In IssueBadge

On the same settings page, scroll to Automatic provisioning (SCIM).
Click Generate token. Copy the token immediately. It is shown only once; use Regenerate token if you lose it.
Note the SCIM base URL: https://app.issuebadge.com/scim/v2.

In the Okta Admin Console

Open the IssueBadge app and select the Provisioning tab, then click Configure API Integration.
Tick Enable API integration.
API Token: paste the token generated in IssueBadge. (The base URL is pre-configured in the OIN listing; if a Base URL field is shown, enter https://app.issuebadge.com/scim/v2.)
Click Test API Credentials. You should see "IssueBadge was verified successfully". Click Save.
Still on the Provisioning tab, select To App under Settings and click Edit.
Enable Create Users, Update User Attributes and Deactivate Users. Leave Sync Password off. Click Save.

Back in IssueBadge the provisioning status changes to Active and shows when the token was last used.

3.5 Attribute mappings

IssueBadge stores a small profile. On the Provisioning → To App page, scroll to Attribute Mappings and keep exactly these attributes mapped:

IssueBadge attribute	Okta value	Used for
userName	user.email	Unique identifier and sign-in email
givenName	user.firstName	First name shown in the team list
familyName	user.lastName	Last name shown in the team list
email	user.email	Notification address (same as userName)

No other attributes are used. Any extra attribute Okta sends (title, phone, department, address and so on) is accepted and ignored, so you can safely remove those mappings.

3.6 Assign people and groups

Open the Assignments tab of the IssueBadge app.
Click Assign → Assign to Groups (recommended) or Assign to People, pick the group or person, and click Save and Go Back, then Done.
With provisioning on, each assigned person appears in IssueBadge under Settings → Team within a minute, with the role chosen in step 3.3.
To remove access, unassign the person or group, or deactivate the person in Okta. Their IssueBadge account is deactivated; their certificates remain.

Only assigned people can sign in through Okta. If a person is assigned but provisioning is off, their account is created on first sign-in when "Create accounts on first sign-in" is ticked.

4. SP-initiated SSO

People can start from IssueBadge instead of the Okta dashboard:

Go to https://app.issuebadge.com/sso, or open https://app.issuebadge.com/login and click Sign in with SSO.
Enter your work email and click Continue. IssueBadge finds the workspace for that email domain and redirects you to your Okta org.
Sign in to Okta (including any MFA your org requires). You are returned to IssueBadge already signed in.

Okta-initiated sign-in also works: click the IssueBadge tile on the Okta End-User Dashboard. Both flows use the same OpenID Connect settings.

5. Troubleshoot

"Your email domain is not allowed for this workspace."

The person's email domain is not in Email domains. Add it under Settings → Single sign-on and provisioning and save.

"No IssueBadge account exists for this email. Ask your administrator to add you."

"Create accounts on first sign-in" is off and the person has not been provisioned. Either assign them to the app with provisioning on, tick "Create accounts on first sign-in", or invite them from Settings → Team.

"This email already belongs to another IssueBadge workspace."

The email is registered in a different IssueBadge workspace (for example a personal trial). IssueBadge never moves accounts between workspaces. The person can sign in to that workspace with their password, or contact support@issuebadge.com to have the account moved. In Okta this shows as a provisioning error with a "uniqueness" (409) response for that person.

"Your account has been deactivated. Please contact your administrator."

The person was unassigned or deactivated in Okta, or deactivated under Settings → Team. Reassign or reactivate them in Okta; provisioning reactivates the account.

Test sign-in fails or Okta shows a "400 Bad Request" page

Check the Issuer URL: it must be your Okta org URL only (for example https://acme.okta.com) with no path. Check that the Client ID and Client secret were copied completely. If your org uses a custom domain, use that domain as the issuer.

"Test API Credentials" fails in Okta (401 Unauthorized)

The token is missing, mistyped or has been revoked or regenerated in IssueBadge. Generate a new token, paste it into Configure API Integration and test again. Each workspace has one active token; regenerating invalidates the previous one.

Provisioning error when unassigning the workspace owner

Expected. The owner cannot be deactivated through Okta so a workspace can never lock itself out. Transfer ownership in IssueBadge first if the owner is leaving.

A person signed in but cannot see billing or team settings

They received the Developer role. Change "Role for new people" to Company admin for future accounts, or change their role under Settings → Team.

"No single sign-on is set up for this email domain."

Single sign-on is not turned on for that domain. Tick Single sign-on is on and make sure the domain is listed under Email domains.

Still stuck? Email support@issuebadge.com with your workspace name, the Okta org URL and the exact error text, or call +1 972-559-4922.

6. Questions admins ask

Does IssueBadge support SAML with Okta?: The OIN listing uses OpenID Connect, not SAML. Okta-initiated sign-in (the tile on the End-User Dashboard) and IssueBadge-initiated sign-in (app.issuebadge.com/sso) share the same OIDC settings, so there is nothing extra to configure for either direction.
Is this included on every plan?: Yes. Single sign-on and SCIM provisioning come with every IssueBadge plan. The only restriction is who can switch them on: the workspace owner, under Settings → Single sign-on and provisioning.
What happens to someone's certificates when they are deactivated in Okta?: Nothing. Their IssueBadge account is deactivated, and that is all. Certificates they issued, verification pages and audit history stay where they are. Reactivate them in Okta and the account comes back.
Can Okta deactivate the workspace owner?: No, on purpose. Unassigning the owner returns a provisioning error and the owner keeps access, so a workspace cannot lock itself out. If the owner is leaving, transfer ownership in IssueBadge first.
What goes in the Issuer URL field?: Your Okta org URL and nothing else: https://acme.okta.com, or your custom domain if you have one. No /oauth2/default. Check it first whenever Test sign-in fails or Okta shows a "400 Bad Request" page.
Do existing team members lose their accounts when SSO goes on?: No. They are matched by email the first time they sign in through Okta. Provisioning does the same: if an account with that email already exists in the workspace, Okta links to it instead of creating a second one.
We use Microsoft Entra, Google Workspace or another IdP. Same steps?: Close to it. The IssueBadge side is identical: any OpenID Connect provider goes into the same settings page, and the SCIM endpoint is the same. Only the Okta-specific screens differ. See the SailPoint page for the SCIM-only setup, or email support for another provider.

Okta configuration guide for IssueBadge