Configure SSO with a custom OIDC connection

​

Before you start

• The Admin role 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

​

Setup steps

1

Open the SSO configuration portal

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.

2

Verify your domain

The portal takes you to the domain verification step. The Domain verification guide 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.

3

Select the custom OIDC option

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.

4

Create an application in your authorization server

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. 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.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.

5

Add claims to the ID token

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 and not in the ID token, continue without adding them to the ID token and turn on Use userinfo endpoint in Step 6.

6

Provide your OIDC configuration

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.

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.

7

Test single sign-on

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. 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.

8

Enable SSO

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.

​

Troubleshooting

​

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 if you need help during setup.