SSO Overview
SecureCodingHub supports Single Sign-On via OpenID Connect (OIDC) and SAML 2.0. SSO lets your team sign in with their corporate identity provider — no separate passwords needed.
Supported Protocols
SecureCodingHub supports two industry-standard SSO protocols:
OIDC (OpenID Connect)
Modern OAuth 2.0 based protocol. Recommended for Azure AD, Okta, and most cloud identity providers. Uses authorization code flow with PKCE.
SAML 2.0
XML-based federation protocol. Supported for legacy identity providers and enterprise environments.
How SSO Works
When SSO is configured for your organization, the login flow works as follows:
User navigates to SecureCodingHub login
Enters their email — system detects SSO is configured for their org domain
Browser redirects to your identity provider (Azure AD, Okta, etc.)
User authenticates with corporate credentials
IdP redirects back to SecureCodingHub with auth token
SecureCodingHub creates a session and logs the user in
JIT Provisioning
When SSO is enabled, users are automatically created on first login — this is called Just-In-Time (JIT) provisioning. New users are assigned the Learner role by default. Your organization must have available seats for new users to be provisioned.
Configuration URLs
Use the following URLs when configuring your identity provider:
| Setting | Value |
|---|---|
| OIDC Callback URL | https://api.securecodinghub.com/api/sch/auth/sso/callback/oidc |
| SAML ACS URL | https://api.securecodinghub.com/api/sch/auth/sso/callback/saml |
| SP Metadata URL | https://api.securecodinghub.com/api/sch/auth/sso/metadata |
Choosing between SAML and OIDC
If your identity provider supports both protocols, the practical answer is to pick what your security team already operates and trusts. OIDC is the newer, JSON-based protocol built on OAuth 2.0. It is friendlier to develop against, easier to debug, and the default option in most modern IdPs including Azure AD and Okta. For organizations standardizing on cloud-native tooling, OIDC is usually the right pick.
SAML is the older, XML-based federation standard, and it remains the most common choice in enterprise environments. The reason is rarely technical preference. It is that the IdP team already runs dozens of SAML integrations, the certificate rotation calendar is established, and the in-house playbook for SAML troubleshooting is mature. If you are deploying into an environment with PingFederate, ADFS, or a legacy SAML IdP, choosing SAML lets you reuse existing patterns instead of asking the IdP team to support a one-off OIDC integration. Either protocol provides equivalent security; the choice is about operational fit, not cryptography.
Pre-SSO checklist
Before you enable SSO in production, plan around three realities. First, set up a test environment or use a tenant you control end-to-end. Misconfigured SSO can lock everyone out, including the admin who configured it. Run the full login flow against a non-critical org first, ideally with a throwaway IdP application, so you can iterate on attribute mapping without urgency. Second, keep at least one fallback admin account that does not rely on SSO. SecureCodingHub honors a break-glass local admin path, and the time to test it is before SSO goes live, not at 9 PM on a Friday when something has gone wrong.
Third, think through the downstream impact on email-based invitation flows. Once SSO is active, users from your verified domain are redirected to the IdP and JIT-provisioned on first login. This means an admin who manually invites users by email and a directory administrator who assigns the app in the IdP can both create accounts, and the two streams will collide if you do not pick one. The cleaner pattern is to disable manual invitations for the SSO-managed domain and let the IdP be the single source of truth. See the SAML setup guide and protocol-specific guides for the next step.
SSO: frequently asked
What does SSO stand for, and what problem does it solve?
SSO stands for Single Sign-On. It is an authentication pattern that lets a user sign in once with their corporate identity provider and then access multiple downstream applications — including SecureCodingHub — without re-entering credentials. The point is not just convenience; it lets your security team enforce password policy, MFA, and offboarding in one place rather than per-application.
SSO vs SAML — are they the same thing?
No. SSO is the user-facing pattern; SAML is one of the protocols that can implement it. When you compare SSO vs SAML, the cleaner framing is that SAML 2.0 is a federation standard that carries the authentication assertion from your identity provider to the application, and SecureCodingHub speaks it. OIDC (built on OAuth 2.0) is the modern alternative for the same SSO outcome.
SSO vs OAuth — what's the actual difference?
The SSO vs OAuth distinction trips people up because OIDC sits on top of OAuth 2.0. OAuth 2.0 by itself is an authorization framework — it grants an application access to a resource. OIDC adds an identity layer on top, which is what makes OAuth-based SSO possible. So OAuth 2.0 alone does not give you SSO; OIDC over OAuth 2.0 does.
Can I use SSO with an open source identity provider?
Yes. Because SecureCodingHub supports the open standards — SAML 2.0 and OIDC — any open source SSO identity provider that implements them works. Keycloak, Authentik, and Zitadel are common picks for teams that want to self-host the IdP. The configuration steps on the SecureCodingHub side are identical to those for Azure AD or Okta; you supply the metadata or discovery URL and map the attributes.