The test window shows an error from my provider and never comes back. What now?

Your provider refused the request before sending anyone back to Cavuno, so the drawer keeps waiting. The most common cause is a redirect URI mismatch: copy the callback URL from the drawer into your provider again, exactly as shown. Then close the test window and click Test connection again.

Why can't I switch off the last sign-in method for a role?

Every role keeps at least one working sign-in method, so nobody is locked out by accident. Switch on another method for that role first.

I closed the drawer and my new connection is gone. Why?

A new connection is a draft until you save it after a passing test. Closing the drawer discards the draft. Add the connection again, and update the callback URL in your provider: the new connection has a new one.

Troubleshooting SSO

What each SSO connection test error means and how to fix it, plus redirect URI mismatches, unassigned users, email confirmation, SSO-only lockout rules, and sign-in errors on your board.

By Abi Tyas Tunggal and Jack Walsh

Start with the message in the drawer. When a Test connection run fails, the line above Test connection and Save says what went wrong and what to check, and the field it points at shows the fix. View details lists what your provider sent, when it sent anything.

Set-up guides: Set up SSO with Okta and Set up SSO with any OpenID Connect or OAuth 2.0 provider.

Test errors

The drawer shows the message. The code is what the SSO connections API returns in the connection's latest test result. This table adds the usual cause.

Code	Message in the drawer	Usual cause and fix
`issuer_mismatch`	The discovery document names a different issuer than the connection.	The issuer URL differs from the one the provider reports, often by a trailing slash or a path such as `/oauth2/default`. The Issuer URL field shows the value your provider reports: use exactly that.
`discovery_failed`	The provider discovery document could not be loaded.	The issuer URL is wrong, or the provider publishes no OpenID Connect discovery document there. Check that `{issuer}/.well-known/openid-configuration` opens in a browser. If the provider publishes it elsewhere, set Discovery URL under Advanced. If the provider has no discovery document, use OAuth 2.0.
`provider_unreachable`	The provider could not be reached, or its address is not reachable from Cavuno.	A URL has a typo, the provider is down, or it sits on a private network. Cavuno reaches your provider over the public internet.
`invalid_response`	The provider response could not be validated.	A URL points at a web page instead of the provider's API, or the provider sent something malformed. Check each URL against your provider's documentation.
`protocol_unsupported`	Provider endpoints must use https.	Every provider URL must start with `https://`.
`provider_error`	The provider returned an error.	Your provider refused the request and sent the error back. Check the application registration and that the callback URL is registered there. The error name after the colon comes from your provider.
`access_denied`	Your provider refused the sign-in. Check that this person is assigned to the app in your provider.	Your provider did not let this person use the application, usually because they are not assigned to it: see User not assigned. When the provider says the person canceled or declined, the drawer shows Sign-in was canceled. instead: test again and finish signing in at the provider.
`token_exchange_failed`	The token endpoint refused the code.	The Client ID or Client secret is wrong, the secret expired, or the callback URL registered at your provider differs from Cavuno's. Paste the secret's value, not its ID.
`audience_mismatch`	The ID token was issued for a different client ID.	The Client ID in Cavuno belongs to a different application. Copy it again from the application you registered for Cavuno.
`signature_invalid`	The ID token signature does not verify against the provider keys.	The issuer URL points at a different authorization server from the one that signed the sign-in. Check the issuer URL.
`nonce_mismatch`	The ID token nonce does not match this sign-in.	The response belongs to a different sign-in, usually an old test window. Close other test windows and test again.
`state_mismatch`	The provider response does not belong to this sign-in.	As above: close other test windows and test again.
`token_expired`	The ID token has expired.	Test again. If it repeats, the provider's clock is wrong.
`token_time_invalid`	The ID token claim is out of range.	The provider sent a sign-in dated in the future. Check the provider's clock, then test again.
`id_token_missing`	The provider did not return an ID token.	The `openid` scope is missing. Add it under Advanced → Scopes, or switch the protocol to OAuth 2.0 if the provider does not support OpenID Connect.
`userinfo_failed`	The userinfo endpoint request failed (or answered an HTTP error, or the response is too large or not a JSON object).	Check the Userinfo URL, and that the scopes grant access to it. The response must be a JSON object under 64 KB.
`subject_mismatch`	The userinfo response is for a different user than the ID token.	The provider's userinfo endpoint answered for someone else. This is a provider problem: contact its support.
`subject_missing`	The provider did not send the subject claim.	The Member ID claim name under Advanced does not match anything your provider sends. Open View details, pick the claim that holds each person's stable ID (not the email), and enter its name.
`email_missing`	The provider did not send an email address in the email claim.	Add the `email` scope, or set Email under Advanced to the claim that holds each person's email. View details lists what your provider sent.
`config_changed`	The connection settings changed while the test was running.	The settings were saved or changed during the test, possibly in another tab. Test again.

The drawer can also refuse to start a test:

Your browser blocked the test window. Allow pop-ups for Cavuno and try again.
Too many tests on this connection in the last 10 minutes. Wait a few minutes, then try again.
Fill in the provider details, then test the connection. A required field is empty.
You need permission to manage settings to test connections. Ask an owner or admin.

Redirect URI mismatch

If the test window shows an error page from your provider, such as "redirect_uri mismatch" or "The redirect_uri parameter must be a Login redirect URI", your provider does not recognize the callback URL. It shows the error in its own window and never sends you back, so the drawer keeps waiting.

Copy the callback URL from 1. Add this callback URL in the drawer.
Paste it into your provider's allowed redirect URIs, exactly as shown, with no extra slash or spaces.
Close the test window and click Test connection again.

Each connection has its own callback URL. If you closed the drawer for a new connection and started again, the callback URL changed: update it in your provider.

User not assigned

Many providers only let assigned people use an application. In Okta, a person who is not assigned sees "User is not assigned to the client application" or "You are not allowed to access this app", and the test ends with Your provider refused the sign-in. Check that this person is assigned to the app in your provider.

Assign the person, or a group they belong to, in the application's Assignments tab in Okta (or your provider's equivalent), then test again. The same applies to members signing in to your board later: only assigned people can sign in.

Email not verified and confirmation emails

A test can pass with an email marked (not verified). That is not an error: your provider sent the email but did not say it is verified. Okta developer orgs often have unverified emails.

When a person signs in with an unverified email, Cavuno confirms it itself:

A new account gets a 6-digit code by email.
An existing account with the same email gets a confirmation link by email. The SSO sign-in is linked once the person opens the link in the browser where they started signing in. The link expires after 15 minutes.

If your provider never says whether an email is verified and your organization alone decides each person's email there, you can switch on Trust the provider's email under Advanced to skip the confirmation. See Trust provider emails.

Save is unavailable

Save needs a test that passed on exactly the settings in the drawer:

Test the connection first (shown when you hover over Save): no test has passed on these settings yet.
Test again to save your changes (shown above the buttons): you changed a provider setting (issuer, client ID, client secret, or anything under Advanced) after the last test.

Changing only the name, logo, Who can use it, or New people on a saved connection needs no new test.

Closing the drawer discards changes

A new connection is a draft until you save it. Closing the drawer, with its close button or Esc, deletes the draft: nothing is added, and the next attempt gets a new callback URL.

On a saved connection, closing the drawer drops unsaved changes. Sign-ins keep using the saved settings until you save a change that passed a test.

SSO-only roles and lockout rules

Every role keeps at least one working sign-in method, so you cannot lock people out by accident:

The last method switched on for a role cannot be switched off. The switch says Candidates need at least one way to sign in. (or Employers).
An SSO connection that is a role's only method cannot be switched off or removed. It says Switch on another sign-in method for candidates first (or employers).
A connection cannot be switched on until a test passed on its saved settings: Test the connection to switch it on.

Switching off the last built-in method while an SSO connection covers the role makes the role SSO only. Cavuno asks you to confirm first, and can sign out people in that role who have not linked SSO yet. See Make a role SSO only.

Once a role is SSO only, its sign-in page shows only the SSO button, and every other way in is refused, including a password sign-in through the API, which fails with board_auth_method_unavailable.

When a member's SSO sign-in fails, your board's sign-in page shows a message. A frontend built with the SDK receives the reason as error= on /auth/sign-in:

Code	What happened	What to do
`sso_cancelled`	The person canceled at the provider, or the provider refused them.	Check that the person is assigned to the application at your provider.
`sso_failed`	The provider's response failed a check.	Run Test connection in the drawer to see the exact error.
`sso_state_invalid`	The sign-in expired or was already used, for example after the back button.	Start the sign-in again.
`sso_connection_unavailable`	The connection is removed or switched off for this role.	Switch it on for the role in Settings → Sign-in methods.
`sso_not_provisioned`	New people is set to Only people who already have an account, and this person has none.	Add the person to the board first, or change New people.
`sso_email_required`	The provider sent no email for a first sign-in.	Add the `email` scope or fix the Email claim name.
`sso_account_disabled`	The person's board account is deactivated.	Reactivate the account if they should have access.
`sso_identity_linked_elsewhere`	This provider account is already linked to a different board account.	The person signs in to the board account the provider account is linked to.
`sso_link_proof_rate_limited`	Too many confirmation emails for this account.	Wait, then sign in again.
`role_disabled`	Accounts for this role are turned off on the board.	Turn the role back on in Settings → Features.

Next steps

If the drawer's message and this page do not explain a failure, contact support with the connection name and the message the drawer shows.