Okta single sign-on
Okta can be used to sign your colleagues in to 3rdRisk, so they reach the platform from your corporate identity with one click instead of keeping a separate password. You configure it yourself in the platform, and nothing changes for your users until you switch it on.
This article covers the Okta side of the setup and the fields that are specific to it. Everything that applies to every provider — how the connection test works, what happens to accounts that do not exist yet, and how to switch single sign-on on — is described in the main article.
Start here for the shared steps: Single sign-on
Overview
You create an OIDC web application in Okta, copy two values out of it into 3rdRisk, paste one value back into Okta, and add your Okta domain.
Permissions needed: Configuration settings (read and update). To grant it, navigate to: Left menu: Configuration, then Roles.
Available for: an administrator of both systems. You need an Okta administrator account and access to Configuration in 3rdRisk.
Note: single sign-on does not create accounts by itself. Either the person already exists in 3rdRisk, or you fill in Default roles so that they are created on their first sign-in.
1. Open the SSO settings in 3rdRisk
- Navigate to: Left menu: Configuration, then General, then the SSO tab.
- Set SSO Provider to Okta.
The page then shows a Redirect URI, generated from your platform address. You need it in the next step. Leave this page open.
2. Create the application in Okta
- Sign in to the Okta Admin Console with an administrator account — your Okta domain followed by
/admin, for examplehttps://your-org.okta.com/admin. - Open Applications, then Applications, then Create App Integration.
- Choose OIDC — OpenID Connect, select Web Application, then Next.
- Enter a name, for example
3rdRisk, paste the Redirect URI from the 3rdRisk SSO page, then Save. - On the application's General tab, copy the Client ID and the Client secret.
3. Enter the details in 3rdRisk
Back on the SSO tab, fill in:
Field | Value |
|---|---|
SSO Provider | Okta |
Client ID | Client ID from the application's General tab |
Client Secret | Client secret from the same tab |
Base URL | your Okta domain, for example |
Redirect URI | generated for you — this is the value you pasted into Okta |
Support Email | the address your own users should contact about sign-in problems |
Tenant ID and Token URL Path are not used by Okta. Leave them empty.
Click on Save.
4. Choose how users are identified
Under Identity provider, Username Type decides which value is matched against the account in 3rdRisk:
- Email address — the default, and the right choice for most organisations.
- User Principal Name (UPN) — use this only when you match on UPN deliberately.
5. Enable single sign-on
Once your settings are saved, switch Enable SSO on. Unlike Microsoft Entra ID, Okta does not require a connection test first — but running one anyway is the cheapest way to find a wrong secret or a mistyped redirect URI before it affects everyone.
The test, its three possible results and the order of saving and enabling are described here: Single sign-on
Known limitations
- A connection test never stores the client secret. Save your settings before testing.
- The Base URL is your Okta domain, not the application URL. Use
https://your-org.okta.com, without a path. - The redirect URI must match exactly. Okta compares it character for character, so paste it rather than retyping it.
- MFA is your provider's responsibility. The Require two-factor authentication for 3rdRisk sign-in setting applies only while the provider is 3rdRisk, and the MFA enforcement setting is specific to Microsoft Entra ID. With Okta, configure the requirement in your Okta sign-on policy.