Set up SSO with Okta

This guide connects Okta to your job board with OpenID Connect, so candidates and employers can sign in with their Okta account. You create an app in the Okta Admin Console, paste its details into Cavuno, run a test, and save.

Before you begin

You'll need:

• Admin access to your Okta org (the Super Administrator or Application Administrator role).
• Owner or admin access to your Cavuno board.

Keep two browser tabs open: Cavuno and the Okta Admin Console. You copy values in both directions.

Start the connection in Cavuno

1. In Cavuno, go to Settings → Sign-in methods and click Add SSO connection.
2. Set Provider to Okta.
3. Enter a Name: your organization's name, for example "Acme Members". People see it on the sign-in button as Continue with Acme Members.
4. Under 1. Add this callback URL in Okta, click the copy button. The URL looks like https://cavuno.com/api/board-auth/sso/…/callback.

Leave the drawer open. If you close it before you save, Cavuno discards the new connection and you start again, including a new callback URL.

Create the app in Okta

1. In the Okta Admin Console, go to Applications → Applications and click Create App Integration.
2. Choose OIDC - OpenID Connect as the sign-in method.
3. Choose Web Application as the application type, then click Next.
4. Enter an App integration name, for example "Acme job board". Okta shows it on its own sign-in page.
5. Under Grant type, keep Authorization Code selected. Cavuno does not need any other grant type.
6. Under Sign-in redirect URIs, remove the example URI and paste the callback URL you copied from Cavuno, exactly as shown.
7. Under Sign-out redirect URIs, remove the example URI and leave the list empty. Cavuno does not use it.
8. Under Assignments (Controlled access in some orgs), choose who can sign in to your board:
   • Allow everyone in your organization to access, or
   • Limit access to selected groups, then pick the groups.
9. Click Save.

Okta changes its console labels from time to time. If a label differs, follow Okta's guide to creating an OIDC app integration.

Copy the client ID and secret

On the app's General tab, under Client Credentials:

1. Copy the Client ID.
2. Keep Client authentication set to Client secret.
3. Under Client Secrets, copy the secret's value. Use the value, not the secret's ID.

Okta's Require PKCE as additional verification setting can stay on or off. Cavuno always uses PKCE.

Choose the issuer URL

The issuer URL tells Cavuno which Okta authorization server signs people in.

• Your Okta domain, such as https://acme.okta.com. This is the org authorization server. Every Okta org has it, and it is the right choice unless you already use a custom authorization server. Find your domain in the menu under your username at the top right of the Admin Console.
• A custom authorization server, such as https://acme.okta.com/oauth2/default. Use it if your organization already runs its sign-ins through one, for example to add custom claims. Find the exact value under Security → API → Authorization Servers, in the server's Issuer URI column.

Cavuno fills in the https://{yourOktaDomain}/oauth2/default pattern as a hint. Replace it with your own value; the form refuses a URL that still contains {yourOktaDomain}. If your org uses a custom Okta domain such as login.acme.com, use that domain.

Finish in Cavuno

1. Under 2. Paste the details from Okta, fill in:
   • Issuer URL: the issuer you chose above.
   • Client ID and Client secret: the values from Okta.
2. Optionally add a Logo under Sign-in button. The preview shows the button as people see it.
3. Under Who can use it, Candidates and Employers start switched on. Switch off any role that should not use Okta. Under New people, choose Create an account on first sign-in, or Only people who already have an account if you add every person to the board yourself.
4. Click Test connection. A window opens on Okta's sign-in page. Sign in with an Okta user who is assigned to the app.
5. The window closes and the drawer shows Test passed. Click View what Okta sent to check the member ID, email, and name Okta returned.
6. Click Save.

Save stays unavailable until a test passes on exactly the settings in the drawer. If you change a provider setting after a test, the drawer says Test again to save your changes. If the test fails, the drawer says what to fix. See Troubleshooting SSO.

The defaults under Advanced fit Okta: OpenID Connect, the openid email profile scopes, and the standard claim names. You do not need to change them.

Check who is switched on

After you save, the connection appears in the Settings → Sign-in methods table with its Candidates and Employers switches. You can change them there at any time. The Continue with Acme Members button appears on your board's sign-in page for each role you switched on.

To have a role sign in only with Okta, switch off every other method for that role. See Make a role SSO only.

Email verification with Okta

Okta sends an email_verified claim with each sign-in. When it is true, Cavuno trusts the email: a board account with the same email is linked and signed in straight away. When it is false, Cavuno confirms the email itself:

• A person without a board account gets a new account and a 6-digit code to confirm their email.
• A person whose email matches an existing board account gets a confirmation link by email. Their Okta sign-in is linked to that account once they open the link in the same browser.

Okta developer orgs often have users whose email is not verified, so expect these emails while you test. In a production org, users usually verify their email when they activate their Okta account.

Because Okta sends email_verified, the drawer shows Okta confirms verified emails — no setting needed under Advanced after a passing test, and Trust the provider's email is not offered. That setting is for providers that never say whether an email is verified. See Trust provider emails.

Next steps

• Troubleshooting SSO lists every test error and what to change.
• Set up SSO with any OpenID Connect or OAuth 2.0 provider covers other identity providers and member systems.
• Sign-in and accounts explains per-role switches and the rules that keep every role able to sign in.