Okta (OIDC) Setup
Step-by-step guide to configure Single Sign-On with Okta using OpenID Connect.
Prerequisites
- Okta admin account
- SecureCodingHub org admin account
Step 1 — Create an Okta Application
Go to Okta Admin Console → Applications → Create App Integration
Sign-in method: OIDC
Application type: Web Application
App name: SecureCodingHub
Sign-in redirect URI: https://api.securecodinghub.com/api/sch/auth/sso/callback/oidc
Assignments: Assign to your users/groups
Step 2 — Copy Credentials
Collect the following values from your Okta application:
| Setting | Where to Find |
|---|---|
| Client ID | General → Client Credentials |
| Client Secret | General → Client Credentials |
| Okta Domain | Your Okta URL (e.g. dev-12345.okta.com) |
| Discovery URL | https://{okta-domain}/.well-known/openid-configuration |
Step 3 — Configure SSO in SecureCodingHub
Log in as Org Admin → SSO Settings
Protocol: OIDC
Entity ID / Client ID: paste your Okta Client ID
Discovery / Metadata URL: paste your Okta OpenID configuration URL
Client Secret: paste the secret
Enable SSO
Click Save
Step 4 — Test
Open an incognito/private browser window
Go to SecureCodingHub login
Enter an email address with your organization's domain
You should be redirected to Okta login
After authentication, you should be logged into SecureCodingHub
Common Okta SAML pitfalls
Although this guide focuses on OIDC, many Okta tenants run SecureCodingHub over SAML, and the same Okta-specific issues recur. The first is an audience URI mismatch. Okta calls this field Audience URI (SP Entity ID) in the SAML General Settings, and the value must match exactly what SecureCodingHub publishes as its entity ID. A common mistake is to enter the SecureCodingHub website URL rather than the API entity ID. Verify the value against the SP Entity ID field in the SecureCodingHub SSO Settings page before saving the Okta application.
The second pitfall is the Okta app sign-on policy. Okta applies an application-level policy that can require additional factors, restrict by network zone, or deny access entirely based on group membership. If an end user reports that SSO redirects them to Okta and then bounces back with an access-denied error, the cause is almost always an app sign-on policy rule that does not match the user. Check Sign On Policy under the application and confirm the rule that applies to the test user. The third common pitfall is mismatched Name ID format. Okta defaults to Unspecified, but SecureCodingHub expects emailAddress format. Set Name ID format to EmailAddress in the application settings and confirm the source attribute is user.email or user.login.
How to verify SSO is working end-to-end
Verification starts in an incognito browser session to avoid any cookies from prior logins. Navigate to the SecureCodingHub login page, enter a corporate email address with your verified domain, and confirm the browser redirects to your Okta tenant. After authenticating at Okta, the redirect should land you in SecureCodingHub on the dashboard for the correct organization. If you land on a generic landing page or a 404, the most likely cause is that the user does not yet exist in SecureCodingHub and JIT provisioning is disabled or rejected the create event.
Second, verify role and seat assignment. The JIT-provisioned user lands with the default Learner role. If your tenant uses role mapping from Okta group claims, validate that the expected groups appear in the user profile. Third, sign out, then sign back in. The second login should be near-silent thanks to the Okta session cookie. If the second login forces a full re-authentication, the Okta session lifetime is set too short for normal use; adjust the global session policy or the application sign-on policy accordingly. For protocol-level details, see the SAML setup guide.