Setting Up Single Sign-On (SSO)

Last updated: March 31, 2026

Single Sign-On (SSO) allows your users to access the Pursuit platform through your organization’s identity provider (IdP) using one set of credentials. Pursuit supports both OpenID Connect (OIDC) and SAML 2.0 protocols for SSO. This guide will walk you through the setup for each, with clear explanations of the required fields, where to find the information in common IdPs (like Okta), and how to configure those IdPs to work with Pursuit.

Pursuit SSO Endpoints and Required Information

No matter which protocol you use, you’ll need some information from Pursuit to set up the connection in your IdP. Here are the key Pursuit SSO details (you will use these in your IdP configuration):

Note: Pursuit requires that at least one test user be assigned to the Pursuit application in your IdP. This is important for validation – many IdPs will not allow unassigned users to access a newly created SSO integration. After configuring SSO, always test login with a designated user to verify the integration.

Setting Up SSO via OpenID Connect (OIDC)

When enabling OIDC SSO in Pursuit, you will typically need to provide or configure the following fields:

  • Issuer / Discovery URL: This is the identifier and configuration URL for your OIDC provider. The “Issuer” is a URI that identifies the IdP; often you can enter the discovery URL and Pursuit will auto-fetch the details.

  • Client ID: A unique ID that identifies the Pursuit application to the IdP. When you register Pursuit as an application in your IdP, the IdP will provide a Client ID (sometimes called “Application ID”). This is essentially a public identifier.

  • Client Secret: A secret string (like a password) issued by the IdP for the Pursuit application.

  • Scopes (Claims): Scopes tell the IdP which user info to include in the ID token or make available. Pursuit requires certain scopes to get the necessary user details. At a minimum, include:

    • OpenID: The base scope for OIDC (required to get an ID token).

    • Profile: To get basic profile info (usually name, username).

    • Email: To get the user’s email claim.

    • Groups: To request group/role info (if you plan to use group-based permissions) . This scope is optional but recommended if you want Pursuit to receive the user’s group memberships in the token.

  • Logout Endpoint (Optional): If you want logging out of Pursuit to also log the user out of your IdP, provide the IdP’s logout URL. Pursuit will redirect the user to this URL when they sign out, ending their session at the IdP as well.

Setting Up SSO via SAML 2.0

When enabling OIDC SSO in Pursuit, you will typically need to provide or configure the following fields:

  • Identity Provider (IdP) Metadata: This is usually the easiest way to configure SAML. It’s an XML file or URL that contains all the necessary info about your IdP: the SAML Entity ID (a unique identifier for your IdP), the SSO URL (where Pursuit should send authentication requests), and the IdP’s public signing certificate.

  • NameID Format & Attribute: Pursuit expects the SAML NameID to be the user’s email address if possible. Besides the NameID, Pursuit requires additional user attributes to provision or identify the user: email, firstName, lastName, groups.

  • Signature & Encryption Requirements: Pursuit’s SAML implementation will verify signatures on the SAML response or assertion using the IdP’s certificate. Ensure in your IdP settings that the SAML response or assertion is signed. Pursuit will use the certificate (from metadata or the one you upload) to verify this signature.

    • Pursuit can also sign the AuthnRequest it sends to the IdP (using that auth.pursuit.us/pem certificate). If your IdP has a setting like “Require signed requests” you can enable it and upload Pursuit’s cert to allow verification. This adds security by ensuring the IdP only accepts SSO requests from authorized SPs.

    • Encryption: Pursuit does not require encrypted SAML assertions by default. The SAML exchange is over HTTPS which is encrypted in transit. However, if your IdP mandates SAML encryption or you prefer to enable it, you would use Pursuit’s public cert (the same pem file) as the encryption certificate in the IdP. The IdP will then encrypt the assertion for Pursuit, and Pursuit will decrypt it with its private key.

Conclusion and Next Steps

Once either OIDC or SAML SSO is configured and tested with a user, you can proceed to roll it out to your organization by assigning all relevant users or groups to the Pursuit application in your IdP. Pursuit will then allow those users to authenticate via your IdP, streamlining access.