Authentication

Authentication Methods

Choose the authentication method that best fits your organization:

Magic Code Flow

The default passwordless authentication flow works as follows:

SSO Flow

When SSO is configured for your organization, the authentication flow changes:

JWT Tokens

All authenticated sessions are managed using JSON Web Tokens:

Session Security

• Tokens are validated on every API request
• Invalid or expired tokens are rejected
• SSO sessions respect IdP session policies
• Magic codes are single-use and time-limited

Authentication design choices SecureCodingHub made and why

The default authentication path on SecureCodingHub is passwordless. We made that decision deliberately. The vast majority of credential compromises we see in customer training data still trace back to password reuse, weak password choices, and phishing of static secrets. Removing the password from the primary login flow eliminates a class of failure modes that no policy can fully mitigate. For organizations that require a traditional password fallback, we enforce minimums consistent with current NIST guidance: a length floor rather than a complexity ruleset, screening against known breached password corpora, and no forced rotation in the absence of evidence of compromise.

Email-based recovery is intentionally retained even for SSO-backed accounts. When an identity provider becomes unreachable, or when a contractor's corporate directory entry is removed mid-engagement, we still need a deterministic, auditable path back into the account for the verified owner. The recovery channel is rate-limited, single-use, and logged separately from the standard login event stream so that security teams can detect anomalous recovery activity without it being lost in normal login noise.

Shared accounts are discouraged at the product level rather than blocked outright. We surface a warning in the admin console when usage patterns suggest a single seat is being shared across multiple humans, because shared seats break individual accountability, distort progress reporting, and complicate any future incident investigation. Organizations that need cross-team access to dashboards should use role assignment and the SCIM-provisioned learner roles described in Data Security rather than reusing credentials.

Mapping authentication to compliance

SecureCodingHub is preparing for SOC 2 Type II and has not yet completed an audit, so we do not claim certification. We do, however, design the authentication subsystem against the same control families that a security team would expect when evaluating a vendor for that audit. SOC 2 CC6.1 expectations around logical access — unique identification of each user, multi-factor or equivalent step-up for sensitive actions, and revocation on termination — are addressed through per-user accounts, the magic code or IdP-issued credential as the second factor, and SCIM-driven deprovisioning.

ISO 27001 Annex A.9 controls covering access control policy, user registration, and privileged access are addressed through documented role definitions, organization-scoped registration restricted to verified domains where requested, and separation of the Platform Admin role from tenant-level Org Admin permissions. For organizations subject to PCI DSS section 8, the relevant control is that we never store cardholder data and never authenticate cardholders against the platform; SecureCodingHub is a training environment, not a payments environment, so the surface that PCI applies to is intentionally narrow.

None of the above should be read as a substitute for your own assessment. Evidence packages including subprocessor lists, data flow diagrams, and current audit posture are available on request from security@securecodinghub.com.

What changes when SSO is enabled

Enabling SSO is not just a swap of one login screen for another — it changes several runtime behaviors that security teams should understand before rollout. Once your organization is connected to an identity provider, the local magic code path is no longer offered to users whose email matches your verified domain. They are redirected to your IdP instead. This is the correct default, but it means recovery during an IdP outage shifts entirely to your IT team rather than SecureCodingHub support. We recommend documenting that escalation path internally before turning SSO on for a large user base.

Audit log entries are enriched when SSO is active. In addition to the standard login event, we record the issuing IdP, the authentication method asserted by the provider (for example, whether MFA was satisfied at the IdP), and the session lifetime returned in the assertion. This gives you a single place to correlate platform activity with your central identity logs during an investigation. Lockout behavior also shifts: rate-limited failed attempts on the local magic code path no longer apply to the same user once SSO is in effect, because all credential validation happens at the IdP. Lockout policy is then governed by your IdP configuration, not by SecureCodingHub defaults.