Set up SSO with any OpenID Connect or OAuth 2.0 provider

Works with any member system that supports OpenID Connect or OAuth 2.0. Candidates and employers click Continue with your organization's name on your board, sign in with the account they already have, and come back signed in to your board.

Using Okta? Follow Set up SSO with Okta instead.

Before you begin

You'll need:

• Admin access to your provider, enough to register an application (sometimes called a client, an app integration, or an OAuth app).
• Owner or admin access to your Cavuno board.
• To know which protocol your provider supports. If you're not sure, ask your IT team or your member system's support. Look for "OpenID Connect", "OIDC", or "OAuth 2.0" in its documentation.

How it works

Cavuno uses the authorization code flow with PKCE for both protocols:

1. A person clicks the sign-in button on your board.
2. Your provider asks them to sign in, then sends them back to Cavuno's callback URL.
3. Cavuno checks the response, reads who they are, and signs them in to your board.

Your provider identifies each person with a member ID, a value that never changes for that person. Cavuno links the member ID to one board account. The next time the person signs in, Cavuno finds them by member ID, even if their email changed at the provider.

Start the connection in Cavuno

1. Go to Settings → Sign-in methods and click Add SSO connection.
2. Set Provider:
   • Other provider (OpenID Connect) for a provider that supports OpenID Connect.
   • Other provider (OAuth 2.0) for a provider that supports only OAuth 2.0.
3. Enter a Name: your organization's name. People see it on the button, for example Continue with Acme Members.
4. Under 1. Add this callback URL in your provider, click the copy button.

Leave the drawer open while you work in your provider. If you close it before you save, Cavuno discards the new connection, including its callback URL.

Register Cavuno with your provider

In your provider's admin area, create an application for your board:

1. Choose a web application, or a confidential client, that uses the authorization code grant.
2. Add the callback URL from Cavuno as an allowed redirect URI, exactly as shown. Some providers call it a sign-in redirect URI, a callback URL, or a reply URL.
3. Leave any sign-out or logout redirect URI empty. Cavuno does not use it.
4. Allow the scopes Cavuno asks for (see Scopes).
5. If your provider decides which people can use each application, assign the people or groups who should sign in to your board.
6. Save, then copy the client ID and the client secret. Copy the secret's value, not its ID.

Paste the details into Cavuno

Under 2. Paste the details from your provider, fill in the fields for your protocol.

OpenID Connect

• Issuer URL: the provider's issuer, such as https://login.example.org. Cavuno reads the rest from {issuer}/.well-known/openid-configuration. The issuer must match the issuer value in that document exactly, including any path and trailing slash.
• Client ID and Client secret.

OAuth 2.0

• Issuer URL: an identifier for the provider, usually its base URL. Cavuno uses it to tell providers apart; changing it later unlinks everyone who signed in with the connection.
• Authorization URL: where people sign in, such as https://login.example.org/oauth/authorize.
• Token URL: where Cavuno exchanges the sign-in code, such as https://login.example.org/oauth/token.
• Userinfo URL: an API endpoint that returns the signed-in person as a JSON object, such as https://login.example.org/api/me.
• Client ID and Client secret.

Every URL must start with https://, and your provider must be reachable from the public internet.

Choose the sign-in button and who can use it

1. Optionally add a Logo under Sign-in button. The preview shows the button as people see it.
2. Under Who can use it, Candidates and Employers start switched on. Switch off any role that should not use this connection.
3. Under New people, choose what happens when someone without a board account signs in:
   • Create an account on first sign-in, or
   • Only people who already have an account, if you add every person to the board yourself. Anyone else is turned away.

Advanced settings

Advanced holds the settings the provider choice fills in. A test shows what your provider sends, so run one before you change anything here.

• Protocol: OpenID Connect, or OAuth 2.0 with a userinfo endpoint.
• Discovery URL (OpenID Connect only): leave blank to use the issuer's standard discovery document. Set it only if your provider publishes its discovery document somewhere else.
• Scopes, and the Claim names described below.
• Trust the provider's email, described below.

Scopes

Scopes are separated by spaces.

• OpenID Connect: the default is openid email profile. Keep openid: without it the provider sends no ID token. email and profile ask for the email address and name.
• OAuth 2.0: there is no standard. Enter the scopes your provider's documentation lists for reading the signed-in user's profile and email, or leave the field blank if the userinfo URL needs none.

Claim names

Claims are the named values your provider sends about a person. Cavuno reads four of them:

Leave a field blank to use the default. If your provider uses different names, for example member_id or user.email, enter them here. After a test, View what your provider sent lists every claim your provider sent, so you can pick the right one.

Trust provider emails

When your provider says an email is verified, Cavuno trusts it. When your provider does not, Cavuno confirms the email itself before linking it to an existing account:

• 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 SSO sign-in is linked to that account once they open the link in the same browser.

If a test shows your provider sends the email-verified claim, the drawer says your provider confirms verified emails and no setting is needed.

If your provider never says whether an email is verified, Trust the provider's email appears. Switch it on only if your organization alone decides which email each person has at the provider, for example a member system where staff set every address. Then a matching board account is signed in without a confirmation email. Leave it off if people can type in any email at the provider: anyone who can sign in there with an address could sign in to the board account that uses it.

Test and save

1. Click Test connection. A window opens on your provider's sign-in page. Sign in as a person who is allowed to use the application.
2. The window closes and the drawer shows Test passed. Click View what your provider sent to check the member ID, email, and name.
3. Click Save.

Save stays unavailable until a test passes on exactly the settings in the drawer. A test creates no account and signs no one in to your board. If it fails, the drawer says what to fix. See Troubleshooting SSO.

After you save, the connection appears in the Settings → Sign-in methods table. Its Candidates and Employers switches work like every other method's. To have a role sign in only with SSO, see Make a role SSO only.

Where people see the button

The Continue with … button appears on the sign-in page of boards built with the AI website builder, for each role you switched on. A frontend you build yourself with the SDK reads the connections from board.context() and starts the sign-in with board.auth.getSsoAuthorizationUrl. See SSO connections in the auth reference.

Test from localhost or a preview

A sign-in returns to your board's own address. To try SSO on a frontend running on your computer or on a preview deployment:

1. Go to Settings → SDK and add the address, such as http://localhost:3000, under Development origins.
2. In your frontend, identify the board with its publishable key (pk_...) and pass developmentOrigin when you start the sign-in. The auth reference shows how.

Confirmation emails can only link to a localhost development origin. On a preview address, test with a person whose email your provider confirms.

Next steps

• Troubleshooting SSO lists every test error and what to change.
• Sign-in and accounts explains per-role switches and the rules that keep every role able to sign in.