Configure Okta SSO

Sanitized AI supports an Okta OpenID Connect (OIDC) connection that uses the authorization code flow. Don’t turn it on for everyone until the connection and a real assigned user have both passed their tests.

Where to find each setting

The following table shows where each setting lives.

You need	Go here
Sanitized AI SSO, domain approval, and access policy	Sanitized AI > My Organization > Sign-in & provisioning
Create or edit the Okta app	Okta Admin Console > Applications > Applications
Okta’s field-by-field OIDC reference	Create OpenID Connect app integrations (Okta documentation)
SCIM instead of sign-in	Configure SCIM provisioning
Other sign-in methods	Choose how people sign in

The Okta setup progress card at the top of Sign-in & provisioning tracks the four stages: configure and check Okta, get company domains approved, test assigned users, and enable Okta. Your progress is kept between visits.

1. Create an Okta OIDC application

1. Sign in to the Okta Admin Console.
2. Go to Applications > Applications.
3. Click Create App Integration.
4. Choose OIDC - OpenID Connect, and then choose Web Application.
5. Click Next, and give the integration a recognizable name, such as Sanitized AI production.
6. Under Grant type, select Authorization Code. Don’t use the implicit flow.
7. Leave Sign-in redirect URIs for now. You paste the value from Sanitized AI in the next section.
8. Save the integration, and assign only a small pilot group.

The connection needs the openid, profile, and email scopes. Keep them allowed in your authorization server and consent settings.

Tip

Use a dedicated integration for Sanitized AI rather than reusing one from another service. It keeps redirect URLs, secret rotation, and audit logs easier to manage.

2. Add the Sanitized AI URLs to Okta

1. In Sanitized AI, go to My Organization > Sign-in & provisioning.
2. Find the Enterprise SSO card.
3. Copy each of the following values into the matching field in Okta, and then save the Okta integration:
   • Sign-in redirect URI: add it as an Okta sign-in redirect URI.
   • Login initiation URL: use it for an Okta dashboard tile, if you want one.
   • Post-logout redirect URL: add it as an Okta sign-out redirect URI.

Always copy these values from Sanitized AI rather than typing them from documentation. They’re generated for your organization.

3. Connect Okta and test the connection

1. In Okta, open the new application’s General tab.
2. Copy its Client ID and Client secret.
3. Find the issuer URL of the authorization server that serves the application. Use the authorization server’s issuer, not your Okta admin URL or organization URL.
4. In Sanitized AI, go back to My Organization > Sign-in & provisioning > Enterprise SSO.
5. Paste the issuer into Okta issuer URL, and the client ID into Client ID.
6. Paste the client secret into Client secret, and then click Create connection.
7. Click Test connection. Don’t continue until the test succeeds.

Sanitized AI doesn’t show the client secret again. To rotate it, enter the new secret and click Update connection. To keep the current secret while you change other fields, leave Client secret empty.

4. Get each sign-in domain approved

1. In Company domain approval, enter a company email domain, such as example.com, without @ or a user name.
2. Click Submit domain. The domain shows pending approval.
3. Wait for Sanitized AI to approve it.
4. Repeat for every domain that will use Okta.
5. When a domain shows approved, click Test Okta sign-in and sign in as a real user who is assigned to the Okta application. The domain then shows sign-in tested.

No DNS record is needed.

Caution

An approved domain doesn’t prove that the Okta app is assigned correctly. Always complete the real-user test before you turn on Okta for everyone.

5. Turn on Okta sign-in

When the connection test has passed, at least one domain is approved, and each approved domain has passed a real-user test:

1. Go to My Organization > Sign-in & provisioning > Access policy.
2. Select Enable Okta sign-in.
3. Optional: to create accounts the first time people sign in, select Automatically create users from approved domains.
4. Optional: when you’re ready to stop other sign-in methods for everyone except admins, select Require Okta for regular users.
5. Click Save access policy.

Ask a pilot user to sign out and sign in again with Okta. Check that their account appears on the Users page.

Admins whose email is at an approved company domain always keep email sign-in links as an emergency way in, even when Okta is required or Enable email magic-link sign-in is cleared. The link only helps an admin who can still open their email, so if your mailboxes also sign in through Okta, make sure at least one admin can read their email without it. For what each access policy setting does, see Choose how people sign in.

Troubleshooting

The following table lists common problems.

Symptom	Check
The connection test fails	Confirm that the issuer is the authorization server’s issuer. Then check the client ID, the client secret, and all three redirect URLs.
Okta can’t be turned on	Complete the connection test, domain approval, and a real sign-in test for every approved domain.
A user isn’t recognized	Check that their email domain is approved and that they’re assigned to the Okta application.
The browser extension can’t sign in	Check that the user can sign in to the web dashboard first, then update the extension to the latest version.
Only admins can sign in	Okta was turned off, for example after you updated the connection or a connection test failed, and no other method is on. Only admins at an approved company domain can sign in, with an email link. Turn on email, Google, or Microsoft sign-in in Access policy. Or click Test connection again, repeat Test Okta sign-in for each approved domain, and turn Okta back on.
You need to remove Okta	First turn on email, Google, or Microsoft sign-in in Access policy and click Save access policy. Until one of them is on, Disconnect is unavailable, so people can still sign in. Then, in Enterprise SSO, click Disconnect.