SAML single sign-on for career-assessment and hiring platforms — built, connected on request.

Yes — SAML 2.0 sign-in is a built capability on JobCannon’s B2B and institutional platform, layered on the same identity system (Supabase Auth / GoTrue) that already handles Google sign-in. It is not a self-serve toggle in a settings page: connecting an identity provider is something we do per organization, on request, rather than a generic switch every customer can flip on their own. Because the build targets the SAML 2.0 protocol itself rather than one vendor’s proprietary API, any standards-compliant SAML 2.0 identity provider works once connected — Okta, Microsoft Entra ID (Azure AD), OneLogin, PingFederate and ClassLink have all been the target of the build and testing. Today, sign-in on every B2B and institutional plan is Google — Google Workspace accounts included, because a Workspace account is a Google account — and no customer has a SAML connection live yet. If SAML is a requirement for your rollout, say so in the form on this page and we scope the connection with you.

District IT usually asks this about staff and counsellor accounts, not students. Most K-12 rollouts put students on a class code or Google Workspace for Education, which is already native sign-in and does not need SAML at all; SAML is aimed at the layer district IT actually administers — administrators and counsellors signing in through the district’s own identity provider instead of a personal or shared Google account. That is what the build supports: connect Microsoft Entra ID, ClassLink or Okta as your district’s provider, register the staff email domain against it, and staff sign in through the district’s own login screen from then on. Be precise about what this is not: it is sign-in, not roster provisioning. Clever Secure Sync, OneRoster and automatic SCIM account creation or removal are separate, unbuilt integrations — a district asking for class lists, sections and enrollments to arrive automatically from ClassLink or a student information system is asking for a larger, different build than SAML sign-in alone, and we would rather say that here than have a procurement review find it.

Same underlying capability, different buyer. An HR or recruiting team connecting Okta or Microsoft Entra ID gets its recruiters and hiring managers signing into JobCannon’s B2B dashboard through the company’s own identity provider instead of a Google account — useful the moment an employer wants a hiring-assessment tool inside its existing access-review and offboarding process, since a recruiter who leaves the company loses access through the IdP the moment their company account is disabled, rather than needing a second, manual step inside JobCannon. It does not include SCIM-based automatic provisioning yet: accounts are created on first SSO sign-in, not pushed ahead of time from the IdP, so a new hire on the recruiting team still has to attempt a first sign-in before an account exists for them. If SCIM provisioning is a hard requirement for your security review, tell us — it is a distinguishable, larger build than SAML sign-in and we track it separately from this one.

Nobody loses access and nobody is silently re-seated. Connecting SAML for a domain does not merge or overwrite an account that already exists under Google sign-in — a person who already has a JobCannon account keeps that account and their role, because the identity system keys an SSO login separately rather than matching purely on email address. Someone from your organization who has never signed in before is seated automatically on their first SSO sign-in, at a deliberately conservative default role rather than administrator — a shared institutional domain such as a district or a company puts many people behind one domain, and handing every one of them administrator access on arrival would be the wrong default. An admin promotes people to the access they need after that first sign-in, the same as today.

Four things worth naming, because a procurement review asks about all four and a platform that dodges the question is the one that loses the deal. First, there is no self-serve toggle — an organization cannot connect its own identity provider from a settings page; we do it together, on request. Second, there is no SCIM provisioning or deprovisioning — accounts are created on first sign-in, not pushed from your directory ahead of time or removed automatically the moment someone leaves your IdP. Third, there is no roster-sync layer riding on top of SSO — Clever Secure Sync, OneRoster and SIS write-back are separate, unbuilt integrations, and a district’s class lists and enrollments do not arrive because SAML sign-in is connected. Fourth, SAML has not been turned on in production for a live customer yet — the build exists and has been through its own verification, but the identity-provider connection your organization would use is something we set up specifically for you once you ask, not something already running for someone else that you opt into.

Tell us — that is the real first step today, since there is no self-serve path yet. Use the form on this page with your identity provider (Okta, Microsoft Entra ID, OneLogin, ClassLink, or another SAML 2.0-compliant IdP), the domain your team signs in with, and your context (school district, HR team, recruiting agency). We register your domain against your IdP’s SAML metadata, verify the domain so no other organization can claim it, and test a sign-in end-to-end with you before anyone on your team relies on it day to day. There is no published price for SAML SSO specifically — it is scoped as part of the plan conversation, not sold as a separate checkout line item today.