Skip to main content
This page covers Step 3 (creating the application) and SCIM setup for Okta. Everything else — entering credentials, testing, enabling SSO, access policy — is the same for all providers and is covered in SSO Setup.
Copy the callback URL from G360 first. Go to Settings → SSO Settings and copy the read-only Callback URL from the Identity Provider section. You paste it into Okta below.

​
Create the OIDC application

Console: your Okta admin console — the address ending in -admin, not the end-user dashboard, which has no Applications menu. Applications → Applications → Create App Integration. Once saved, the app’s General tab shows these settings back to you in two sections.
Okta General Settings panel showing app integration name G360 SSO, application type Web, and Authorization Code ticked under core grants

General Settings — the app integration name, Application type (Web) and Grant type (Authorization Code).

Okta Login section showing sign-in redirect URIs, sign-out redirect URIs and Login initiated by App Only

The Login section, further down the same page — Sign-in and Sign-out redirect URIs.

Do not choose “Skip group assignment for now.” It leaves nobody assigned, and Okta then refuses every sign-in with “You are not allowed to access this app. To request access, contact an admin.”If you already created the app this way, fix it under the app’s Assignments tab → Assign → Assign to People or Groups.
If you chose Allow everyone in your organization to access, the Assignments tab shows “This app is implicitly assigned to users” instead of an Assign menu. That is correct — access is already granted org-wide and is governed by your sign-on policies.
Okta Assignments tab showing the message This app is implicitly assigned to users with a Configure Sign On Policy button

The Assignments tab when access was granted org-wide — Okta reports the app as implicitly assigned rather than offering an Assign menu.

​
Collect the credentials

From the app’s General tab, under Client Credentials, copy the Client ID and Client secret.
Okta Client Credentials section with Client ID, Client authentication set to Client secret, and a masked secret with a reveal icon

Client Credentials — the Client ID, the client authentication method, and the client secret, masked by default.

Use the eye icon to reveal the secret, then the copy icon to take it.
Treat the secret like a password the moment it is visible. If a screenshot showing it in the clear is ever shared, generate a new secret and update G360.
Okta Client Secrets table with the secret value revealed and redacted, alongside a Generate new secret button

The same section with the client secret revealed. The value is redacted in this screenshot.

​
Issuer URL

Use Okta’s org authorization server:
Issuer URL
Not https://<your-org>.okta.com/oauth2/default/.well-known/openid-configuration.The /oauth2/default custom authorization server adds an access-policy layer on top of app assignment, and a newly created app is not included in that policy by default. It fails after a successful login with “Policy evaluation failed for this request, please check the policy configurations.” The org authorization server needs no such policy and is all G360 requires.
Paste the URL into a browser and confirm it returns JSON before continuing.

​
Next: enter the details in G360

You now have the Client ID, Client Secret and Issuer URL. Return to Step 4 of the setup guide to enter them, test the connection, save, and turn on single sign-on.

​
SCIM provisioning

The application you created for SSO has no Provisioning tab. Okta does not offer SCIM provisioning on OIDC application integrations at all. SCIM needs a second, separate application.
First, generate a SCIM token in G360.

​
Add the catalog application

Applications → Browse App Catalog → search for “SCIM 2.0 Test App (OAuth Bearer Token)” and add it as a second application.
Okta app catalog page for SCIM 2.0 Test App (OAuth Bearer Token), showing an Add Integration button and SCIM capabilities

The SCIM 2.0 Test App (OAuth Bearer Token) listing in Okta's app catalog. Add Integration creates the second application.

​
Configure it

  1. Configure its provisioning settings with your G360 SCIM endpoint (shown alongside the token in G360’s SCIM Provisioning section) and the raw bearer token from G360 — no Bearer prefix.
  2. Confirm the attribute mapped to userName is the user’s email address, not a directory username.
  3. Assign the users who need to be provisioned to this application, in addition to your SSO application.
This is a generic Okta test connector rather than one purpose-built for G360. Test create, update and deactivate carefully with a real account before relying on it for your rollout.
Assign every user to both applications. Someone assigned to the SSO app but not the SCIM app can sign in normally but will never be deprovisioned when they leave.

​
Provider-specific errors

If Okta’s own screen shows an error before you’re redirected back to G360, the problem is on its side. For errors that appear after you’re back in G360, see Troubleshooting.