Skip to main content
Single sign-on lets people sign in to G360 using the account they already have with your organization’s identity provider (IdP) — Microsoft Entra ID, Okta, PingOne, OneLogin, Google, Amazon Cognito, or any standards-compliant OIDC provider — instead of a separate G360 password. Once SSO is configured, your identity provider handles authentication end to end. G360 never sees or stores your users’ passwords. Password policies, MFA, and password resets stay under your existing IT controls.
Setting up SSO is a one-time task performed by a G360 administrator. Individual users do not need to configure anything — they just use the Sign in with SSO button.

​
How it works

Setting up SSO involves work on both sides of the connection.
1

In your identity provider

Create an application that represents G360, so your IdP knows about G360 and which users are allowed to use it. The screens and field names differ for every provider.
2

In G360

Enter the credentials from that application, test the connection, save, then turn on single sign-on.
Once the connection test succeeds, you save, and you turn on single sign-on, a Sign in with SSO button appears on the G360 login page. Clicking it redirects the user to the identity provider; after authenticating there, they are redirected back into G360.

​
Before you begin

The super-user account created during G360 setup, or another account with the Admin role. You sign in with an email address and password for this part, because the SSO button is not available until SSO has been configured.
Permission to create and configure applications in your IdP. On some providers, adding a second application for SCIM later needs a higher permission level than creating the sign-in application — this is called out on each provider’s page.
For example yourcompany.com. Only users whose email address is on an allowed domain can sign in through SSO.
Steps 1, 2, 4, 5 and 6 below are the same regardless of which identity provider you use — they all happen inside G360. Step 3 is different for every provider, so open your provider’s page and follow it exactly.

​
Step 1: Open SSO settings

  1. Sign in to G360 with your administrator email address and password.
  2. Select Settings under Administration in the left sidebar.
  3. Open the SSO Settings section. The header shows when the configuration was last updated.

​
Step 2: Copy the callback URL

In the Identity Provider section, find the read-only Callback URL field and click Copy. You paste this value into your identity provider in the next step. Depending on the provider, the field there may be called Sign-in redirect URI, Callback URL, Redirect URI, or Authorized redirect URI.
The callback URL must match exactly in both places, including the trailing slash. A mismatch is the single most common cause of a failed sign-in when everything else looks correctly configured.

​
Step 3: Create an application in your identity provider

Switch to your identity provider’s admin console and create an application for G360. This step is genuinely different for every provider — the console, the field names, and the traps are all vendor-specific.

Microsoft Entra ID

Single-tenant app registration, /v2.0/ issuer URL.

Okta

OIDC Web App, org authorization server.

PingOne

OIDC Web App, Client Secret Post.

OneLogin

Generic OIDC connector, per-user assignment.

Google

Google Cloud OAuth client, test users list.

Amazon Cognito

User pool, confidential app client, verified emails.

Other OIDC provider

Any standards-compliant OIDC provider.

​
Collecting the credentials

Whichever provider you use, you should end up with these three values.
Identity provider application overview showing Environment ID, Client ID, and masked Client Secret

The G360 application in an identity provider console, showing the Client ID and Client Secret.

Treat the client secret like a password. Copy it directly into G360 — do not share it over email or chat. Confirm the issuer URL in your provider’s console rather than typing it from memory; the correct URL depends on your region, tenant, and environment.

​
Step 4: Enter the details in G360

Return to Settings → SSO Settings and fill in the Identity Provider section. If a configuration already exists, click Edit first.
G360 Identity Provider settings form with callback URL, client ID, client secret, issuer URL, and allowed email domains

Identity Provider section filled in with Client ID, Client Secret, Issuer URL, and allowed email domains.

​
Step 5: Test the connection

Click Test Connection. G360 contacts your identity provider using the details you entered and reports the result on screen.
  • Success — a green message confirms the issuer and client credentials were verified. Click Save Changes to store the configuration, then continue to the next step.
  • Failure — the message explains what went wrong, usually an incorrect client ID, client secret, or issuer URL. Correct the value and test again.
G360 SSO Settings showing the Single sign-on toggle on, Amazon Cognito credentials filled in, and a green message confirming issuer and client credentials were verified

A successful test connection. After you save, the Single sign-on toggle appears.

​
Step 6: Enable single sign-on and verify

The Single sign-on toggle appears only after a successful connection test and Save Changes. Until then, users do not see the SSO button.
Once the configuration is saved, turn on the Single sign-on toggle at the top right of the Identity Provider section. The status line changes to Single sign-on is on: “Sign in with SSO” shows on the login page, and a Sign in with SSO button appears on the G360 login page.
G360 login page with email and password fields and a Sign in with SSO button below

G360 login page showing the Sign in with SSO button.

Before telling your team, verify the setup end to end:
1

Open a private or incognito window

This avoids reusing an existing session.
2

Go to the G360 login page and click Sign in with SSO

Confirm that you are redirected to your identity provider.
3

Authenticate with your organization's account

Confirm that you are redirected back into G360.

​
Access policy

The Access Policy section controls who can use single sign-on and what happens when someone new signs in for the first time. Click Save Changes after configuring these settings.
G360 Access Policy settings with new-user provisioning dropdown, default role dropdown, and Enforce SSO toggle

Access Policy section — new-user provisioning, default role, and Enforce SSO.

​
What Enforce SSO looks like to users

When Enforce SSO is enabled, anyone who tries to sign in with an email address and password sees a message on the login page telling them to use their organization’s account and the Sign in with SSO button.
Only enable Enforce SSO after confirming that SSO sign-in works end to end. If the identity provider connection is broken while SSO is enforced, users lose the password fallback. Turning Enforce SSO back off restores password sign-in immediately.
G360 login page showing a red message explaining that this instance requires signing in with the organization's account

The message shown when Enforce SSO is enabled and a user tries to sign in with a password.

​
Roles and what users can see

New SSO users are created with the User role by default. Signing in successfully does not, by itself, grant access to engineering or cost data. A user with this role sees:
No developer data linked to your account yet. Contact your admin.
G360 dashboard showing the message No developer data linked to your account yet

What a newly signed-in user sees before a role with data access is assigned.

To give someone broader access, assign a higher role — such as an engineering or FinOps leadership role — under User & Team Management. The metrics and dashboard sections a person can open depend on the role assigned to them.
A role change takes effect at the next sign-in. Ask the user to sign out and sign back in through SSO to receive their new access.

​
Keep accounts in sync with SCIM

SCIM keeps your G360 user list automatically synchronized with your identity provider — new joiners are created, name changes flow through, and leavers are suspended without an administrator touching anything.

SCIM provisioning

Provider availability, token generation, and what SCIM syncs. Not available on every provider or plan — check before planning a rollout around it.

​
Signing in with SSO

This section applies to everyone in your organization, not just administrators.
G360 login page with email and password fields and a Sign in with SSO button below them

The G360 login page. Use Sign in with SSO rather than the email and password fields.

1

Go to the G360 login page

Open G360 in your browser.
2

Click Sign in with SSO

Use the button below the email and password fields instead of entering a password.
3

Authenticate with your organization's account

You are redirected to your organization’s sign-in page. Enter the credentials you use for your other work applications. If your organization requires MFA or a first-time password change, you are prompted for it here — this is handled entirely by your identity provider, not by G360.
4

You're signed in

After authentication you are redirected back to G360 and taken to your dashboard.
If you see “No developer data linked to your account yet. Contact your admin.”, your sign-in was successful — your account simply has not been assigned a role with access to that data. Ask your G360 administrator to update your role, then sign out and sign in again.

​
Troubleshooting

Possible causes
  • The client ID or client secret was copied incorrectly, or includes a leading or trailing space.
  • The issuer URL points to the wrong environment, tenant, or region.
  • The application in your identity provider is disabled or was never saved.
Resolution
  • Re-copy each value using your provider’s copy button instead of retyping it.
  • Confirm the issuer URL ends in /.well-known/openid-configuration and opens in a browser.
  • Check the application is enabled in your identity provider, then test again.
Possible causes
  • The Single sign-on toggle is turned off.
  • The connection test has not passed, or the configuration was not saved, so the toggle is not available.
Resolution
  • Sign in as an administrator, go to Settings → SSO Settings, run Test Connection, and once it succeeds, click Save Changes and turn on Single sign-on.
Possible causes
  • The callback URL in your identity provider does not exactly match the one shown in G360.
  • The user’s email domain is not listed under Allowed email domains.
  • The user is not assigned to the G360 application in the identity provider.
Resolution
  • Copy the callback URL from G360 again and compare it character for character, including the trailing slash.
  • Add the user’s domain to Allowed email domains and save.
  • Assign the user or their group to the G360 application in your identity provider.
Possible cause — The identity provider reports that the email address on the user’s account isn’t verified. G360 refuses a first SSO sign-in in this case, because an unverified address can’t be trusted to link to, or create, a G360 account. Users who have already signed in through SSO are not affected.Resolution — Verify the user’s email address in your identity provider, then ask them to sign in again. On Amazon Cognito, see Make sure user emails are verified.
Possible cause — Enforce SSO is enabled, which disables password sign-in for everyone on the allowed domains.Resolution — This is expected behavior. Ask the user to use the Sign in with SSO button. If SSO itself is broken, an administrator can turn Enforce SSO off to restore password sign-in while the issue is investigated.
Possible cause — The account was created with the default User role, which provides minimal access.Resolution — Assign a higher role under Administration → User & Team Management, then ask the user to sign out and sign in again. Role changes apply at the next sign-in.
For provider-specific error messages (AADSTS50011, invalid_client, access_denied, and similar), see the troubleshooting section on your provider’s page.

​
Best practices

  • Test before you enforce. Verify SSO sign-in works end to end with a real account before turning on Enforce SSO.
  • Enable SCIM before onboarding at scale, on a provider that supports it, so accounts are created, updated, and deactivated automatically from day one instead of becoming a manual backlog.
  • Keep allowed domains tight. List only the domains your organization actually owns — every extra domain widens who can create a G360 account through SSO.
  • Rotate and revoke SCIM tokens deliberately. Only one token can be active at a time, so plan rotations for a low-traffic window and update your identity provider immediately.
  • Review roles periodically. New SSO users get the least privileged role by default; make sure access still matches people’s current responsibilities.
  • On Entra ID, Okta and OneLogin, watch both applications. These providers split SSO and SCIM across two separate applications. A user assigned to only one either can’t sign in, or can sign in but will never be deprovisioned.