Single sign-on

What single sign-on does

With single sign-on (SSO), the people in your organization sign in to the ModelRiver console through your company's identity provider instead of a ModelRiver password. When someone leaves and you turn off their account at the identity provider, they can no longer get in to your organization.

SSO covers the console: the people who set up projects, workflows, provider keys and API keys. It does not change how your applications call the API. Those keep using API keys.

ModelRiver supports OpenID Connect (OIDC), which Okta, Microsoft Entra ID, Google Workspace, Auth0 and most other identity providers offer.

SSO is available on the Scale and Custom plans. Owners and admins can see the settings; only the owner can change them.

Set it up

Open the organization menu, select Organization settings, then Single sign-on. Setup has three steps, and nothing changes for your members until you finish them.

1. Connect your identity provider

1. Choose your provider: Google Workspace, Okta, Microsoft Entra ID or Other.
2. At your identity provider, create an OpenID Connect web application.
3. Register the Redirect URI shown on the Single sign-on page. Providers also call it the sign-in redirect URI or callback URL.
4. Back in ModelRiver, enter what the page asks for, plus the Client ID and Client secret from that application, and save.

What the page asks for depends on the provider:

Choose Other for any other OpenID Connect provider, and for an Okta custom authorization server.

When you save, ModelRiver contacts the provider to confirm it is a working OpenID Connect provider. An issuer URL must use HTTPS and must be entered exactly as the provider reports it. If they differ, the error message shows the value to use.

The client secret is stored encrypted and is never shown again. To change it, enter a new one and save.

2. Verify your email domain

Add the email domain your company uses, such as company.com. ModelRiver shows a DNS TXT record:

Add the record at your DNS provider, then select Verify. DNS changes can take a few minutes to appear.

Only people whose email address is on a verified domain can sign in with SSO. This is what stops an identity provider from signing someone in as an address your company does not own. A domain can be verified by one organization at a time, and public email providers such as gmail.com cannot be added. You can add up to 20 domains.

3. Try it

Select Sign in with SSO on the Single sign-on page and sign in through your identity provider. This confirms the connection works for you before you require it of everyone.

Members can now choose Continue with SSO on the sign-in page and enter their work email.

Provider setup guides

Okta

1. In the Okta Admin Console, open Applications, select Create App Integration, then OIDC - OpenID Connect and Web Application.
2. Under Sign-in redirect URIs, add the Redirect URI from ModelRiver.
3. Assign the people or groups who should have access.
4. In ModelRiver, choose Okta, enter your Okta domain, for example your-company.okta.com, and the Client ID and Client secret from the application's General tab.

Microsoft Entra ID

1. In the Entra admin center, open App registrations and select New registration.
2. Under Redirect URI, choose Web and add the Redirect URI from ModelRiver.
3. Under Certificates & secrets, create a client secret and copy its value.
4. Under Token configuration, add the optional claim email for ID tokens, so ModelRiver receives each person's email address.
5. Entra ID usually does not say whether an email address is verified. If sign-ins fail with "Your identity provider didn't confirm your email address", turn off Only accept verified email addresses on the Single sign-on page (see Verified email addresses).
6. In ModelRiver, choose Microsoft Entra ID, enter your Directory (tenant) ID, and use the Application (client) ID as the Client ID. The shared common and organizations endpoints can't be used, because they accept accounts from any Microsoft tenant.

Google Workspace

1. In the Google Cloud console, open APIs & Services, then Credentials, and create an OAuth client ID of type Web application.
2. Under Authorized redirect URIs, add the Redirect URI from ModelRiver.
3. Set the OAuth consent screen's user type to Internal, so only people in your Workspace can sign in.
4. In ModelRiver, choose Google Workspace.

With Google, only Google Workspace accounts on one of your verified domains can sign in. A personal Google account is refused, even when it uses a company email address.

Verified email addresses

By default, ModelRiver only accepts an email address that your identity provider marks as verified. Okta and Google Workspace do this.

Some providers, Microsoft Entra ID among them, often send no such mark. For those, the owner can turn off Only accept verified email addresses. An address is then accepted when the provider says nothing about it. Before turning it off, make sure people cannot change their own email address at your identity provider. An address the provider marks as not verified is always refused, and the address must still be on one of your verified domains.

Who can sign in

By default, SSO signs in people who are already members of your organization. Invite them first from the Team page.

To let new people join without an invitation, turn on Let new people join by signing in. Anyone your identity provider lets in, with an address on a verified domain, then becomes a member the first time they sign in. Choose whether they join as a Viewer or an Editor. New members are never made admins; change a role on the Team page. Joining still counts against your plan's member limit.

Someone who already has a ModelRiver account with the same email address keeps that account. Their first SSO sign-in links it to your identity provider.

If a member has turned on two-factor authentication for their own ModelRiver account, they are still asked for their code after signing in with SSO.

Require single sign-on

Once SSO works, the owner can turn on Require single sign-on. From then on:

• Members can only reach your organization's projects, logs and settings from a session that signed in with SSO.
• They are asked to sign in with SSO again every 12 hours. Because of this, someone removed at your identity provider loses access to your organization within 12 hours.
• Signing in with a password, Google or GitHub still works for a member's other organizations, but not for yours.
• Members whose email address is not on a verified domain can no longer get in. The Single sign-on page lists them when you turn the requirement on.

You can only turn the requirement on after you have signed in with SSO yourself, so a mistake in the setup cannot lock everyone out, and once two-factor authentication is on for your own account, so you can still get in if your identity provider stops working (see below).

While SSO is required, the identity provider cannot be changed. Turn the requirement off, change the provider, sign in with it yourself, then turn the requirement back on. The client ID and client secret can still be updated. Changing to a different provider also means members are matched again by email address the next time they sign in.

If your identity provider is unavailable

The organization owner can still sign in with their password, as long as two-factor authentication is on for their account. That's why requiring SSO needs it, so keep it on while SSO is required. Every such sign-in appears in the audit log.

The requirement stops applying if the connection is removed, no verified domain is left, or the organization moves to a plan without SSO. Members then sign in the way they did before.

Sessions

Each sign-in creates a session that you can see under Settings, in Active sessions, with the browser, the sign-in method and when it was last used. Select Sign out next to a session to end it. A session that is signed out stops working on its next request.

Resetting your password signs you out on every device. When a member is removed from an organization, their sessions that signed in through that organization's SSO end too.

Audit log

The organization audit log records SSO setup and changes, domains added, verified and removed, the requirement being turned on or off, and each sign-in, including failed ones.

Troubleshooting

• "Single sign-on isn't set up for this email address": the address's domain is not verified for an organization with SSO turned on. Check the spelling, or sign in another way.
• "You don't have access to this organization yet": you are not a member and joining by signing in is off. Ask an admin to invite you.
• "Your email address isn't on a domain this organization has verified": your identity provider reported an address on another domain. Ask the owner to verify that domain.
• "Sign in with your company's Google Workspace account": you chose a personal Google account. Choose your Workspace account at Google's sign-in screen.
• "The TXT record wasn't found yet": the DNS record has not appeared. Check the name and value, wait a few minutes and select Verify again.
• "The provider reports its issuer as ...": enter that exact value as the Issuer URL.
• "Your identity provider didn't confirm your email address": the provider did not mark the address as verified. See Verified email addresses.
• Microsoft Entra ID sign-ins fail: make sure the email optional claim is added for ID tokens.