SSO and SCIM

SSO lets people sign in through your identity provider (IdP) instead of a Forgebench password. SCIM lets your IdP add people to the workspace, and removes their access when you deactivate them there.

SSO & SCIM is under Admin in the sidebar. It needs the admin role and a plan that includes SSO. SCIM is a separate entitlement; if its section is missing, your plan doesn't include it.

Set it up

1. Add and verify your email domain

   Under Email domains, add the domain your people sign in with, for example acme.com. Publish the TXT record shown, then click Verify:

   _forgebench-challenge.acme.com.  TXT  "forgebench-verification=<token>"

   Only people whose email is in a verified domain can sign in through your IdP. A domain belongs to one workspace only.

   Most DNS providers append your domain, so enter _forgebench-challenge as the host. New records can take a few minutes; click Verify again if it misses.

2. Create an app in your identity provider

   Follow the steps for your provider below. You get the redirect URI in the next step, so leave it blank if your IdP allows.

3. Connect it in Forgebench

   Choose your provider, paste the issuer (or metadata URL for SAML) and, for OIDC, the client ID and secret. Click Save connection.

4. Paste Forgebench's URLs back into your IdP

   Once saved, the page shows the Sign-in redirect URI (SAML: ACS URL and Audience URI) and the Initiate login URI for a dashboard tile. Copy them into your IdP app.

5. Sign in

   On the Forgebench login page, click Continue with SSO and enter a work email, or click the tile in your IdP's dashboard.

The client secret is write-only: the console shows whether one is stored, never its value. Leave it blank when editing to keep the current one.

Provider setup

Okta

In the Okta admin console:

1. Applications → Create App Integration → OIDC – OpenID Connect → Web Application, grant type Authorization Code.
2. Client authentication Client secret. Leave Require Demonstrating Proof of Possession (DPoP) unticked, or Okta refuses the sign-in.
3. Sign-in redirect URIs: Forgebench's Sign-in redirect URI. Leave Sign-out redirect URIs empty.
4. Assignments: the people or groups who should get access. Untick Federation Broker Mode: it hides the app from the dashboard, so there's no tile.
5. General → General Settings: Login initiated by Either Okta or App, tick Display application icon to users, Login flow Redirect to app to initiate login, and Initiate login URI is Forgebench's Initiate login URI.
6. Copy the Client ID and Client secret.

In Forgebench, the issuer is your Okta org URL, https://<org>.okta.com (or …/oauth2/default for the default custom authorization server). Don't use the -admin URL.

Microsoft Entra ID

One Entra app handles both sign-in and SCIM. In the Entra admin center:

1. App registrations → New registration, Accounts in this organizational directory only. Redirect URI (Web): Forgebench's Sign-in redirect URI.
2. Certificates & secrets → New client secret. Copy its Value, not the Secret ID next to it; the value is shown only once. Note its expiry (24 months at most) and paste a new one into Forgebench before it lapses.
3. Enterprise applications → the same app → Properties: Assignment required Yes, and Home page URL is Forgebench's Initiate login URI (this is the My Apps tile). Then assign people under Users and groups.

In Forgebench, the issuer is https://login.microsoftonline.com/<Directory (tenant) ID>/v2.0, using the Directory (tenant) ID from the app's Overview, not the Application (client) ID; that one is the client ID. common and organizations are refused, because they'd let in every Microsoft account. Forgebench reads each person's mail from Microsoft Graph, or their UPN if they have no mailbox, so no token claims need configuring.

Google Workspace

In the Google Cloud console, in a project owned by your Workspace organization:

1. Google Auth Platform → Audience: user type Internal.
2. Clients → Create client → Web application. Authorized redirect URI: Forgebench's Sign-in redirect URI. Copy the client ID and secret, or download the JSON, when the client is created.

The project must belong to your Workspace organization; with user type Internal, only its accounts can sign in.

In Forgebench, the issuer is https://accounts.google.com. A personal Google account created with a company email is refused.

Google has no dashboard tile or SCIM for custom apps. People use Continue with SSO, are added at first sign-in, and can't sign in once suspended in Google.

JumpCloud

In the JumpCloud Admin Portal:

1. Access → SSO Applications → + Add New Application → Custom Application, then Manage Single Sign-On and Configure SSO with OIDC. Give it a display label, and tick Show this application in User Portal if you want a tile.
2. Redirect URIs: Forgebench's Sign-in redirect URI.
3. Client Authentication Type: Client Secret Basic.
4. Login URL: Forgebench's Initiate login URI.
5. Attribute mapping: tick the Email and Profile scopes.
6. Click Activate, and copy the Client ID and Client Secret straight away: JumpCloud shows the secret only once.
7. Authorize the user groups who should have access to the app (JumpCloud's Authorize Users to an SSO Application).

In Forgebench, the issuer is https://oauth.id.jumpcloud.com/, or https://oauth.id.eu.jumpcloud.com/ for an EU org and https://oauth.id.in.jumpcloud.com/ for an India org.

Turn on MFA for this app in JumpCloud's conditional access policy.

SAML 2.0

For IdPs that only speak SAML, or a SAML app in Okta or Entra. Create a SAML app with:

• Single sign-on (ACS) URL: Forgebench's ACS URL.
• Audience URI (SP entity ID): Forgebench's Audience URI.
• Name ID format EmailAddress, with the person's email as the value.
• Attributes named exactly firstName and lastName. Without them, people are asked for their name at their first sign-in.
• Signed assertions.

A sign-in whose email differs from the NameID is refused with "That email doesn't match your company sign-in".

In Forgebench, paste the IdP's metadata URL (Okta: the app's Sign On → Metadata URL; Entra: App Federation Metadata Url). It must be reachable from the internet; a downloaded metadata XML file won't work.

For a dashboard tile, hide the SAML app's icon and add a bookmark app pointing at Forgebench's Initiate login URI. Sign-ins started from the SAML app's own tile aren't accepted.

Generic OIDC

Any OpenID Connect provider that publishes <issuer>/.well-known/openid-configuration (WorkOS AuthKit, Auth0, OneLogin, Keycloak…). Create a confidential web app with the Sign-in redirect URI, then paste its issuer, client ID and secret. The redirect URI must match exactly, with no trailing slash.

For WorkOS, the issuer is your AuthKit domain (https://<name>.authkit.app), and the client is an OAuth application under Connect, "managed by you". Turn off AuthKit's social sign-in methods (GitHub and others) unless you want people signing in with accounts your company doesn't manage.

Who can join

New people from your IdP sets what happens when someone without a membership first signs in:

People you invite or provision over SCIM always get in. With Okta or Entra, you can also limit access by assigning the app only to the right people. With Google Workspace, every account in your organization can reach the sign-in, so use approval or invite-only to narrow it.

Enforcing SSO

Enforce SSO makes your IdP the only way in: password sign-in stops working for every member, and AI clients connecting over MCP also go through your IdP. It's available once the connection is saved and a domain is verified.

SSO sign-ins don't ask for a Forgebench two-step verification code, so turn on MFA in your IdP.

SCIM provisioning

1. Generate a token

   Under User provisioning (SCIM), click Generate token. It is shown once. Rotate token replaces it; Revoke stops SCIM entirely.

2. Point your IdP at Forgebench

   Base URL: the SCIM base URL shown on the page (…/scim/v2).

   Okta: add SCIM 2.0 Test App (Header Auth) from the catalog next to your sign-in app, with application username Email. Under Provisioning → Integration, the API token is Bearer <token>. Under Provisioning → To App, enable Create Users, Update User Attributes and Deactivate Users. Assign people to both apps.

   Entra: on your sign-in app, Provisioning, mode Automatic. Tenant URL is the base URL; Secret token is the token without Bearer. Entra syncs about every 40 minutes; Provision on demand pushes one person now.

3. Check Members

   Provisioned people appear under Members. Deactivating someone in your IdP revokes their Forgebench access immediately.

   Okta's Test API Credentials button only checks the token; assign one person to the SCIM app to see a real push.

With Okta, assigned people can click the tile and land in the workspace. With other providers, their first sign-in completes the account.

Signing in, for your team

Share this with your team.

• From your IdP's dashboard: click the Forgebench tile (Okta, Entra My Apps, or a SAML bookmark app).
• From Forgebench: on the login page, click Continue with SSO and enter your work email. The password box goes away; click Continue with SSO again and sign in on your company's page as usual.

The first time, you may be asked to confirm your name and email. If you already have a Forgebench password with that email, enter it once to link the two.

If your workspace approves new people, your first sign-in sends a request to its admins. Sign in again once it's approved.

Signing out of Forgebench doesn't sign you out of your company account. AI clients connecting over MCP also send you through your company's sign-in.

Troubleshooting

Next