Skip to main content
This page covers Step 4 (creating the application) and SCIM setup for OneLogin. Everything else — enabling SSO, entering credentials, 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, turn on Enable single sign-on, and copy the read-only Callback URL from the Identity Provider section. You paste it into OneLogin below.

​
Create the OIDC application

Console: your OneLogin admin console, at the subdomain OneLogin assigned you — not your company’s own domain. It cannot be guessed, and arrives in your account’s activation email. Applications → Applications → Add App → search OpenId Connect (OIDC) → pick the generic OpenId Connect (OIDC) connector.
If the Token Endpoint auth method is left on Basic, the token exchange fails after a successful login and G360 reports it as “identity provider is not finished being set up” — indistinguishable from a missing configuration.

​
Assign access, per user

OneLogin’s Access tab only entitles roles, not people. An application can show a ticked role and still have “No users” on its own Users tab.Assign access under Users → (the user) → Applications → + → pick the app, for every person who needs it.An unassigned user is refused by OneLogin itself with access_denied, which G360 reports as its generic “SSO is not finished being set up” message. If a user reports that error, check whether they’re actually assigned before changing anything in G360.
The two screens below look similar but mean different things — compare them before concluding that someone has access.
OneLogin application Access tab showing policy set to None and a ticked Default role under Roles

The Access tab with a role ticked. This entitles the role; on its own it assigns nobody.

OneLogin application Users tab listing the individual users assigned to the application

The same app's Users tab — the individuals actually assigned. This is the list that decides who can sign in.

OneLogin user profile Applications tab with the add application dialog open to assign an app to that person

Assigning the app to one person, from Users → (the person) → Applications → +.

​
Collect the credentials

From the SSO tab, copy the Client ID, the Client Secret, and the Well-known Configuration link — that link is your Issuer URL.
Copy the Well-known Configuration link with OneLogin’s own copy control rather than typing it.
OneLogin SSO tab showing Client ID, Show client secret, Issuer URL with a Well-known Configuration link, Application Type Web and Token Endpoint authentication method POST

The SSO tab — Client ID, the client secret controls, and the Well-known Configuration link that is your issuer URL.

​
Next: enter the details in G360

You now have the Client ID, Client Secret and Issuer URL. Return to Step 5 of the setup guide to enter them, test the connection, and save.

​
SCIM provisioning

The OIDC application you created for SSO has no Provisioning tab at all. SCIM needs a second, separate application.
First, generate a SCIM token in G360.

​
Add the SCIM Provisioner application

Applications → Add App → search “SCIM” → pick a SCIM Provisioner connector, for example “SCIM Provisioner with SAML (SCIM v2 Core)”.
Don’t be put off by “with SAML” — ignore its SAML half. Only the provisioning configuration is used; your OIDC application keeps handling sign-in.

​
Configuration → API Connection

Save first, then Enable, then Test Connection. The Enable control stays inert until the credentials are persisted.

​
Parameters tab

Set the field OneLogin calls scimusername to your users’ Email attribute.
Set this once on the Parameters tab, not per user. Otherwise OneLogin prompts for scimusername on every individual assignment, and a wrong value silently creates duplicate accounts instead of matching existing ones.
OneLogin SCIM Provisioner Parameters tab listing Groups, NameID mapped to Email, and scimusername mapped to Username

The Parameters tab. Here scimusername is still mapped to Username — change it to Email, or provisioning will never match an existing G360 account.

​
Provisioning tab

  • Enable provisioning.
  • Uncheck “require admin approval” for Create, Update and Delete. Left checked, every action sits in a OneLogin approval queue and nothing reaches G360 — which reads exactly like a broken integration.
  • Set “when a user is deleted or unassigned” to Suspend (or Delete).

​
Assign both applications

Assign every user to both applications under Users → (the user) → Applications: the OIDC application for sign-in, and the SCIM Provisioner for provisioning.
Ticking a user’s role under the Access tab does not assign the application to them — Access only entitles roles, not people. Someone assigned to the OIDC app but not the SCIM app can sign in normally but will never be deprovisioned when they leave.
OneLogin sends different HTTP requests than other providers when updating or removing users (PUT and DELETE, rather than the PATCH other providers use). This needs no configuration on your part — G360 handles it automatically.

​
Provider-specific errors

If OneLogin’s own screen shows an error before you’re redirected back to G360, the problem is on its side. OneLogin’s Activity → Events log, filtered to the user, is authoritative for its half — it records why it refused. For errors that appear after you’re back in G360, see Troubleshooting.