Connecting your organization’s Single Sign-On (SSO) to Audit Sight with Okta using either OIDC or SAML 2.0 is straightforward. This document is a preview of what to expect; we will with your IT staff during setup to determine your exact values for: customer, subdomain, and environment. The final configuration is tailored to your tenant during our joint setup and testing session. Our goal is to complete the integration with an introductory email and a single follow-up video conference to confirm and test the setup. This can typically be accomplished within 1-2 business days.
What You’ll Configure in Okta
You’ll add an Okta OIDC or SAML 2.0 app for Audit Sight and exchange metadata with our team. We support SP-initiated SSO from the Audit Sight login page and IdP-initiated launch from the Okta dashboard. During the call, we’ll confirm and document your three variables:
🔹 customer — your organization identifier used by Audit Sight.
🔹 subdomain — your assigned Audit Sight subdomain (for example, acme).
🔹 environment — the target Audit Sight environment (for example, production or staging).
The next step will depend on if you choose OIDC or SAML 2.0.
Option A: OIDC Configuration
Step 1A: Prerequisites
• Okta admin access to create/configure OIDC applications.
• Ability to share your IdP client ID, client secret, and OIDC well-known endpoint, if available.
• One test user or group to assign to the app.
• Time scheduled with your Audit Sight contact to confirm customer, subdomain, and environment.
Supported features
• IdP-initiated SSO
• SP-initiated SSO
Option B: SAML 2.0 Configuration
Step 1B: Prerequisites
• Okta admin access to create/configure SAML 2.0 applications.
• Ability to share your IdP metadata (XML or Metadata URL).
• One test user or group to assign to the app.
• Time scheduled with your Audit Sight contact to confirm customer, subdomain, and environment.
Supported features
• IdP-initiated SSO
• SP-initiated SSO
Step 2: Create the App in Okta
In the Okta Admin Console, add a new OIDC or SAML 2.0 application:
📌 Use the variable values documented during the initial call:
• Fill in customer, subdomain, and environment variables
• Default RelayState is blank (SAML)
• Signature / Encryption: SHA-256 (SAML)
Step 3: Exchange Metadata & Confirm Variables
Share your IdP Metadata (XML or Metadata URL for SAML) or Client ID, Secret, and Well-Known URL if available (OIDC) with your Audit Sight contact. We'll finalize the connection on our side and confirm your variable values:
🔹 customer — recorded for your tenant.
🔹 subdomain — used to route SSO to your instance.
🔹 environment — directs traffic to the correct environment.
⚠ Note: If you plan to restrict sign-in to SSO only, ensure users are assigned in Okta before enabling enforcement.
Step 4: Test SP-Initiated SSO
Assign a test user/group in Okta and validate with your Audit Sight contact:
1️⃣ Start from the Audit Sight login page (SP-initiated).
2️⃣ Authenticate in Okta and return to Audit Sight.
3️⃣ Verify profile attributes and access to the correct environment.
Pro Tips
✨ Keep it coordinated — we tailor values during setup; no guesswork required.
✨ Start small — validate with a couple of users before broader assignment.
✨ Save metadata — keep your IdP metadata and the SP details for future reference.
After a successful test, users can launch Audit Sight from the Okta dashboard or via SP-initiated SSO from the Audit Sight login page. 🎉
