How-To Set Up Okta SSO for the Crusoe Cloud Console

Introduction

Crusoe Cloud supports Single Sign-On (SSO) to the Crusoe Console using Okta as an OpenID Connect (OIDC) identity provider. Once configured, users you designate are redirected from the Crusoe login page to Okta, authenticate there, and land back in the console with an active session.

The integration is built on a standard OIDC Web Application in Okta. You create the app on your side, register its Issuer URI and Client ID with Crusoe in the console, and share the Client Secret with Crusoe Support through a secure channel. Crusoe then completes the backend configuration and returns a provider ID that you add to your Okta redirect URIs. The console never asks for the Client Secret, which is why the exchange is split across two steps.

SSO is enforced per user, not per organization. Each user in your org has an authentication method (password, Google, or SSO), and only users set to SSO are redirected to Okta. Everyone else keeps signing in exactly as they do today.

That makes migration low risk. You can move users over one at a time and roll any of them back without touching the rest of the org.

New users who sign in through Okta for the first time are provisioned automatically (just-in-time, or JIT) with minimal permissions. An org admin then grants them the roles they need.

Prerequisites

Admin Role on Your Crusoe Cloud Organization
Okta Administrator Access to Create App Integrations
Password Manager That Supports One-Time, Email-Restricted Share Links (for Example, 1Password)

Instructions

Step 1: Ask Crusoe Support to Enable SSO for Your Organization

Open a support ticket at support.crusoecloud.com requesting Okta SSO for your organization. SSO is enabled per organization by Crusoe before the configuration options appear in the console.
Once Support confirms it is enabled, log out of the Crusoe Console and log back in. You should now see Organization > User Authentication in the navigation.

ℹ️ Note: The User Authentication menu only appears on a fresh session. Refreshing the page is not enough. If you do not see it, fully log out and log back in before troubleshooting anything else.

Step 2: Create the Crusoe App Integration in Okta

In the Okta Admin Console, go to Applications > Applications > Create App Integration.
Select OIDC - OpenID Connect as the sign-in method.
Select Web Application as the application type.
Name the app (for example, Crusoe Cloud) and save. You can leave the redirect URIs as defaults for now, because you fill them in during Step 6.

Step 3: Set a Static Issuer URI and Collect Your Credentials

Open your new Crusoe app in Okta and go to the Sign On tab.
Under OpenID Connect ID Token, set Issuer to a static or custom URL, not Dynamic. Copy the resulting Issuer URI. For the Okta org authorization server this is your Okta org URL, for example https://<YOUR_OKTA_ORG>.okta.com.
On the General tab, copy the Client ID and Client Secret.

ℹ️ Note: The Issuer URI must be static. A dynamic issuer will cause SSO logins to fail because Crusoe validates tokens against a fixed issuer value.

Step 4: Add the Identity Provider in the Crusoe Console

In the Crusoe Console, go to Organization > User Authentication.
Click Add Identity Provider.
Enter the Issuer URI and Client ID from Step 3.
Enter the email domains that should be covered by this provider (for example, example.com). Users with these domains who are set to SSO will be routed to Okta.
Save. Your provider should now be listed under User Authentication.

ℹ️ Note: The console does not ask for the Client Secret. You share it separately with Crusoe Support in the next step, and Support applies it on the backend.

Step 5: Securely Share the Client Secret With Crusoe Support

Share the Client Secret through a one-time, email-restricted password manager share link, then post that link on your support ticket. The ticket carries the link, never the secret itself.

⚠️ Warning: Never paste the Client Secret in a ticket comment, email, or chat message. If it is exposed, rotate it in Okta and share the new value the same way.

To create the link in 1Password:

Open 1Password and create or open the item holding the Client Secret (a Secure Note is fine).
Click Share.
Under Expires after, choose After one person views it. The default is 7 days, so change it.
Under who can view, choose the option to share with specific people, click Add email, and enter the email address of the Crusoe support engineer on your ticket.
Click Copy Link and paste the link into your ticket reply.

Because the recipient's email is restricted, 1Password sends a one-time verification code to that address before the secret opens. The link on its own is not enough for anyone else to read it.

💡 Tip: A single-view link is consumed on first open and cannot be reopened, even by the same person. Ask your support engineer to save the secret as soon as they open it.

In the same reply, confirm that you have added the identity provider in the console (Step 4). Crusoe Support will complete the backend configuration and reply with your provider ID.

Step 6: Add the Redirect URIs to Your Okta App

Back in the Okta Admin Console, open your Crusoe app, go to General > General Settings > Edit, and set the following, replacing <PROVIDER_ID> with the value from Support:

Sign-in redirect URIs:

https://console.crusoecloud.com/auth/self-service/methods/oidc/callback/<PROVIDER_ID>

Sign-out redirect URIs:
```
https://console.crusoecloud.com
```

Initiate login URI:

https://console.crusoecloud.com/login/sso

Save the app. Then assign the users or groups who should be able to sign in to Crusoe under the Assignments tab.

💡 Tip: For the Crusoe tile to appear on your users' Okta dashboards, set Login initiated by to Either Okta or App in the same General Settings panel. With App Only, users can still sign in from the Crusoe login page, but not from the tile.

Step 7: Test With a Single User

In the Crusoe Console, go to Organization > Team, find a test user in the active users table, and choose Actions > Edit User Auth. Change the authentication method from Password to SSO.
Confirm that user is assigned to the Crusoe app in Okta.
Have the user sign in either from the Crusoe login page, where they will be redirected to Okta after entering their email, or from the Crusoe tile in their Okta dashboard.

⚠️ Warning: If a user is switched to SSO but is not assigned to the Crusoe app in Okta, they will be locked out. Any org admin can recover them by switching that user's authentication method back to Password under Organization > Team > Actions > Edit User Auth. The user will be prompted to set a new password at their next login.

ℹ️ Note: After changing a user's authentication method, the Team table can take a short time to reflect the new value and may briefly appear to have reverted. Wait a minute and refresh before assuming the change did not save.

You can also test just-in-time provisioning by assigning a brand new user to the Crusoe app in Okta and having them sign in. They will be created automatically in your org with minimal permissions, and an org admin can then assign roles.

Step 8: Migrate the Rest of Your Users

Repeat Step 7 for each user you want on SSO. To invite new users directly onto SSO, go to Organization > Invite Users, enter their email, and select SSO as the login method.

Frequently Asked Questions

Does enabling SSO break Google sign-in for my users?

No. Google sign-in behaves exactly like password sign-in: it only stops working for a user once that specific user's authentication method is set to SSO. Users you have not switched can keep using Google or password as before, so you can migrate at your own pace.

Can I switch all users to SSO at once?

Existing users are switched individually in the console. New users who sign in via Okta are provisioned automatically.

If you need bulk, directory-driven provisioning, de-provisioning, and role assignment, Crusoe supports SCIM with Okta as a separate integration. Open a support ticket to have it enabled and to get the setup guide.

Can I invite new users and require SSO from the start?

Yes. Once your organization has an active identity provider, the invite flow lets you select SSO as the new user's login method. See Step 8.

Is there an API to disable a user or change their auth method?

Not currently. Authentication method changes are made in the console. For automated lifecycle management, use the SCIM integration described above.

A user is locked out after switching to SSO. How do I recover?

Any org admin can open Organization > Team, choose Actions > Edit User Auth for that user, and switch them back to Password. On their next login they will be prompted to set a new password. If the whole org is affected, open a support ticket.

Does SSO manage roles or permissions from Okta?

The SSO integration handles authentication only. Roles are assigned in the Crusoe Console. Just-in-time provisioned users start with minimal permissions until an admin grants more. Role sync from Okta is available through the SCIM integration.

Example

A platform team runs training jobs on Crusoe and has twenty engineers signing in with a mix of passwords and Google accounts. Security policy now requires all production cloud access to go through Okta with MFA.

The team's Okta admin creates the Crusoe OIDC app, sets a static issuer, and registers it under Organization > User Authentication. They share the Client Secret via a one-time 1Password link and receive the provider ID back from Support the same day.

After adding the redirect URIs, they switch one engineer to SSO, confirm the Okta redirect works from the Crusoe login page, and then move the remaining engineers over in small batches during the week. Nobody is locked out during the migration because unmigrated users keep their existing login method until they are switched.

Additional Resources

Related to

how-to okta sso

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.