> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryprofound.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configure SSO with a custom OIDC connection
> Connect your own OpenID Connect authorization server to Profound SSO
Set up Single Sign-On (SSO) with Profound through a custom OpenID Connect (OIDC) connection. Use this guide when your identity provider (IdP) isn't in the SSO configuration portal's list, or when your users authenticate through an authorization server you run yourself rather than your IdP's default one.
**QUICK FACTS**
* SSO setup is **self-serve**. Anyone can complete it and pass the values to their IT team.
* You set up SSO in the configuration portal, which **takes you outside Profound**.
* **Exit the setup and come back anytime**. The values you entered or generated stay in place, and your team keeps signing in as usual until you enable SSO in the last step of this guide.
* **Profound doesn't publish fixed SSO connection values** such as the redirect URI, and you don't need to request them. The portal generates them for your organization as you follow the [setup steps](#setup-steps).
## Before you start
You'll need:
* The [Admin role](/platform-config/people/roles-and-permissions) in your Profound organization
* Administrative access to your IdP and to the OIDC authorization server your users sign in through
* The domain you want to enable for SSO
* Access to your DNS records to verify domain ownership
* An account in your IdP on the SSO domain, for running the test sign-in. You assign this account to the Profound application in [Step 4](#step-4)
## Setup steps
1. In Profound, select your organization name at the top left of the screen, then select **Settings**.
2. Select **Enterprise Setup** under **Organization** in the left navigation sidebar. The **Single Sign-On** card shows your current SSO status and verified domains.
3. Select **Configure SSO** to open the configuration portal.
The portal takes you to the domain verification step. The [Domain verification guide](/platform-config/authentication/sso-domain-verification) walks through this step and its troubleshooting in detail.
After your domain is verified, the **Single Sign-On** card shows the status **In progress** until you enable SSO.
On the identity provider step, select the custom OIDC option instead of a named provider.
The portal switches to the **Custom OIDC** flow, which has its own steps:
1. Provide an Identity Provider Name
2. Create an Application
3. Add Claims
4. Provide your OIDC Configuration
5. Test Single Sign-On
Enter a name for your identity provider and continue.
The portal shows the **Login redirect URI** that your authorization server takes users to after they sign in. It's generated for your connection and doesn't appear anywhere else in Profound. Copy it from the portal.
In your authorization server, create a web application for Profound that:
* Uses the OIDC sign-in method.
* Uses the authorization code grant.
* Authenticates with a client ID and client secret.
* Has Profound's **Login redirect URI** as its sign-in redirect URI. Replace any placeholder your IdP pre-fills, such as a `localhost` address.
* Is assigned to the users or groups who sign in to Profound, including the account you plan to test with.
Keep the application's client ID and client secret for [Step 6](#step-6). If you choose to configure your application to use private key JWT instead of a client secret, register your key as the portal instructs and select that authentication method in [Step 6](#step-6).
Go back to the configuration portal and select **Continue**.
If your custom authorization server has its own access policies, make sure one of them allows the application you created for Profound to request tokens.
The portal lists the claims that Profound reads from the ID token your authorization server issues. For many providers the required claims are included by default. For others, you need to add them to the ID token in your authorization server's settings.
| Claim | Required | Description |
| - | - | - |
| `sub` | Yes | The user's stable and unique ID in your IdP |
| `email` | Yes | The user's email address, which Profound checks against your verified domains |
| `given_name` | Yes | The user's first name |
| `family_name` | Yes | The user's last name |
Add the claims, then select **Continue**.
If your authorization server returns these claims only from its [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) and not in the ID token, continue without adding them to the ID token and turn on **Use userinfo endpoint** in [Step 6](#step-6).
Enter the values from your authorization server:
* **Discovery endpoint**: the URL of your authorization server's OIDC discovery document. For example, `your-company.okta.com/.../.well-known/openid-configuration`.
* **Client ID** and **Client secret**: the credentials of the application you created in [Step 4](#step-4).
To check that you have a correct discovery endpoint URL before you enter it in the portal, open it in a browser: the correct endpoint returns a JSON document whose `issuer` value matches your authorization server.
Expand **Advanced settings** and check that the values match your application. The defaults work for most authorization servers:
| Setting | Default | When to change it |
| - | - | - |
| **Authentication method** | Client secret basic | Select **Client secret POST** or **Private key JWT** if your application is registered with that method instead. With **Private key JWT**, Profound generates the signing key pair. Register the public key with your authorization server so it can verify Profound's sign-in requests |
| **ID token signing algorithm** | RS256 | Select the algorithm your authorization server signs ID tokens with, if it isn't RS256 |
| **Use userinfo endpoint** | Off | Turn on if your authorization server doesn't include the required claims in the ID token. The portal then reads the user profile from the userinfo endpoint listed in the discovery document |
| **Require PKCE** | On | Keep it on unless your authorization server can't complete the sign-in with Proof Key for Code Exchange (PKCE) |
Select **Continue**. The portal checks that the discovery endpoint is reachable before it lets you continue.
When you're ready to test the connection, select **Continue to sign-in**.
The portal redirects you to your authorization server. Sign in with an account on your verified domain that's assigned to the Profound application.
* If the test succeeds, continue to the next step.
* If the test fails, the portal shows the reason. Select **Show session details** for the session ID, which helps when you troubleshoot with your IdP administrator or Profound's [customer support](mailto:support@tryprofound.com). Correct the configuration, then select **Retry Single Sign-On**.
Make sure the account you're using to test the connection is assigned to the Profound application in your IdP.
Run the test as many times as you need. Testing happens in your own Profound organization, and your team keeps signing in as usual until you enable SSO in the next step.
After the test passes, enable SSO for your domain directly from the portal.
Back on the **Enterprise Setup** page, the **Single Sign-On** card status reads **SSO Enabled** and your domain is marked **Verified**. Select **Check status** to refresh.
After you enable SSO, Profound automatically directs users whose email addresses match your configured domains to your authorization server for authentication.
## Troubleshooting
Check that the URL you entered is your authorization server's OIDC discovery document. It must:
* Start with your authorization server's issuer URL
* End with `/.well-known/openid-configuration`
Some users can confuse the discovery endpoint with your authorization server's metadata URL. It looks similar, but it doesn't end with `openid-configuration`.
Your IdP refused to sign the test user in to the Profound application. Make sure that the account you're using to test the connection is assigned to the application in your IdP. If you use an Okta custom authorization server, also confirm that an access policy on that server applies to the Profound application.
## Notes
* Each Profound organization needs its own SSO connection.
* Subdomains can't use the same SSO connection as the root domain: each subdomain needs its own connection.
* Keep each domain's verification TXT record in place for as long as SSO is enabled for that domain.
* Contact [customer support](mailto:support@tryprofound.com) if you need help during setup.