Skip to main content
All CollectionsSSO, SCIM, and User Management
Understanding Your Ideal User Management Setup
Understanding Your Ideal User Management Setup

This document is intended to help admins deploy SSO, and potentially SCIM, in a way that works best with their use-case.

Updated over a week ago

Please review our "SSO Overview" page to familiarize yourself with the key concepts discussed in this document.

Prior to verifying your domains, it’s important to consider a few different questions:

  • How would you like to provision invitations to new users?

  • How would you like to handle existing consumer (personal/Plus) users?

  • What do you want your user login flow to look like?

We'll take a look at each of these questions in more detail to help ensure you're choosing the option that best fits your needs.

Inviting New Users

We currently offer four different methods for provisioning invitations to users:

It's worth noting that we do differentiate between cases where invitation emails are actively sent:

  • A new user is invited for the first time through SCIM

  • OR direct invitations from in-app

And cases where an invitation is silently associated with a user's email in our backend:

  • A SCIM user was removed from your IdP group and then re-added

  • Automatic Account Creation

In the latter case, users will not see the invitations in their inbox, but they will still be properly directed to the corresponding workspace/organization when they try logging in.

SCIM

SCIM is available in both ChatGPT and the API Platform. SCIM allows identity providers (e.g. Okta, Entra ID, etc.) to exchange user identity data with OpenAI, automating the provisioning of invitations (and the de-provisioning of user accounts) based on organizational changes.

While SCIM is also configured through your IdP, it can be setup independently of SSO. Therefore, domain verification/SSO are not requirements for SCIM.

If you decide to use both SCIM and SSO, the important distinction to make is:

  • SCIM only provisions invitations

  • SSO handles the authentication and user creation

We consider SCIM to be the most robust and scalable solution for overall user management. Depending upon your ideal implementation, we generally recommend the following architecture as best practice if you are deploying across both ChatGPT and the API Platform:

With this setup, you can easily manage both invitations and access (to ChatGPT and the API Platform) separately. This setup has the added benefit that any necessary changes can be performed centrally by your administration teams directly in your IdP.

Direct Invitations from ChatGPT or API Platform

Admins can directly invite users by email from the respective ChatGPT and Platform
"Members" pages. In ChatGPT, this method also supports bulk invitations via an uploaded CSV:

While typically not scalable, we often recommend using direction invitations as you're getting started in a new workspace/organization. Unlike SCIM, there is no potential delay for the invitations reaching user inboxes, so it's the most effective option for providing quick access, modifying permissions, and general testing.

Additionally, you can always enable SCIM down the line and bucket your existing users underneath the SCIM application. So there is no concern that directly invited users would be excluded from future automation unless desired.

Automatic Account Creation (AAC)

Contrary to the other options, AAC is only available in the Identity page of ChatGPT and requires SSO to have first been enabled:

As shown above, AAC guarantees that users signing up or logging in with a verified email domain will automatically be added to your Enterprise workspace. The users will not receive an invitation email, and the process is entirely automated. This has its pros and cons.

If your policy is to allow open-door access to any user with your verified domain, AAC is a great option that avoids the added overhead of configuring and managing a SCIM application.

However, AAC is not ideal if you require a more locked-down, approval-based approach to user access.

⚠️ WARNING ⚠️

It's important to keep in mind that enabling AAC will effectively force merge all consumer (personal/Plus) users underneath your domain into your Enterprise workspace. More on this can be found below in the "Handling Existing Users" section.

Note that, even if the users are not members of your IdP access group and are unable to successfully access the workspace if SSO is enforced, they still take up a seat in your Enterprise account in this scenario.

For this reason, we generally recommend SCIM or direct invitations in most cases rather than AAC. And to help avoid potential avenues of confusion, we recommend leaving AAC turned off if you do plan to use SCIM.

API Platform Admin Invites Endpoint

Our API Platform supports an Invites Endpoint, which allows you to programmatically invite users to your API organization.

Compared to SCIM, the major benefit of the endpoint is that it allows you to specify the project(s) the invited user should belong to:

This provides an additional layer of granularity and control, without requiring the manual work of individual direct invitations.

Handling Existing Consumer Users

We define consumer users as those on a personal or Plus subscription. It's often the case that there will be existing consumer users with your verified domain who have had accounts prior to your Enterprise contract. As verifying your domain and enabling SSO can have a downstream impact on these consumer users, it's important to determine the desired outcome beforehand.

Impact on ChatGPT Consumer Users

On the ChatGPT side, the impact to consumers is largely determined by two factors:

  1. Will they be invited to the Enterprise workspace?

    1. If AAC is enabled, then this defaults to "Yes"

  2. Will you enforce SSO?

The resulting behavior can be seen below:

Pending Invite?

SSO Enforced?

Result

Consumer user accounts will be forced to merge to Enterprise, and can only login with SSO

Consumer user accounts will be forced to merge to Enterprise, users can auth with SSO or Social

No impact: Consumer users maintain access to their personal workspaces through Password or Social auth

No impact: Consumer users maintain access to their personal workspaces through Password or Social auth

If your goal is to ultimately prevent any consumer accounts, please reach out to your Account Director to discuss potential options.

Account Merge

The prerequisites to trigger an automatic account merge of the consumer account into an Enterprise account are as follows:

  1. The user's domain is verified

  2. The user has received an invitation to the Enterprise workspace where their domain is verified

    1. ⚠️ Recall that if you've enabled AAC, this condition will always be true for any user with your verified domain.

When these conditions are met, then the next time the user logs into or refreshes ChatGPT, they should see the following modal:

As the image highlights, we will automatically refund any existing Plus subscriptions prior to the merge. Users will have the option to transfer their existing chat history and GPT's, or else export their chat history via email and start their Enterprise workspace as a "clean slate."

Once the consumer account has been merged, there is no way of restoring it. If your users chose the "Transfer existing chat history and GPTs" option but did not see this reflected on their Enterprise workspace, please reach out to Support.

Impact on API Platform Consumer Users

Because SSO on the Platform is still domain-based (versus ChatGPT, where SSO is specific to the workspace where it's been enabled), your consumer users will be impacted as soon as you verify your domain and enable SSO on any organization.

The consumer users will lose the ability to authenticate with passwords, as we identify the domain match and forward them to your IdP. If they are members of your IdP, they can authenticate successfully. Alternatively, they can login with a Social Oauth option if that is available to them. If not, then you have effectively locked them out of their Consumer accounts.

See the User Login section flows for a more in-depth guide to this workflow.

Recommended Identity and Provisioning Patterns

Now that we've laid out the fundamental behavior tied to our identity authentication and invitation provisioning, it may be helpful to review some of the more common implementation patterns available to Enterprise users:

User Login Flow

We've already discussed the impact of pending invitations and SSO enforcement, so this section is meant to help visualize the expected flow/checks we perform when a user types in their email address to login.

ChatGPT Login Flow

Note: This diagram excludes login attempts through a Social method or through the Tile URL.

API Platform Login Flow

Note: This diagram excludes login attempts through a Social method or through the Tile URL.

Next Steps

Now that you have an idea on your ideal implementation, you can follow the respective documentation to enable SCIM or SSO:

Did this answer your question?