Single sign-on (SSO)
Single sign-on lets a person authenticate once with a central identity provider and then reach many applications without signing in again. In K-12 it is standard for staff and students, and almost entirely absent for the population a communications platform serves most: parents and guardians.
| Approach | What it proves | What it does not | Typical K-12 use |
|---|---|---|---|
| SAML 2.0 | An identity provider asserts this person is who they say, with attributes | That the session is still in the right hands ten minutes later | Staff into administrative systems |
| OpenID Connect | The same, over OAuth 2.0 and JSON rather than XML | Anything about authorisation inside the application | Newer applications; Google and Entra logins |
| LTI Advantage | This launch came from a trusted LMS in a known course context | Identity outside that launch context | Instructional tools launched from an LMS |
| Magic link | Control of a mailbox at the moment of sign-in | Anything if the mailbox itself is compromised | Guardians, and any population with no district identity |
| Password | Knowledge of a secret, possibly reused elsewhere | That it has not been reused, phished or breached | The thing everything above is trying to replace |
Three populations, three different answers
Districts tend to reason about SSO as one decision. It is three.
- Staff. Have a district identity, sit in the IdP, are on-boarded and off-boarded by HR. SSO is clearly correct here, and paired with SCIM it closes the orphaned-account problem.
- Students. Have a district identity too, usually federated through Google or Entra and often surfaced through Clever or ClassLink. Same reasoning, with more attention to age-appropriate flows.
- Guardians. Have no district-issued identity at all. There is no IdP record to federate, no HR process, no off-boarding event. A district could mint credentials for every parent, and would then be operating a consumer identity system with password resets, support load and a fresh set of breach obligations, for a population that logs in three times a year.
That last point is why guardian-facing SSO is rare across the whole category, and why the sensible mechanisms for parents are email or SMS possession-based sign-in.
What SSO fixes, and what it does not
SSO is a genuine security improvement and is oversold anyway. Being precise about it makes procurement conversations shorter.
| Threat | Effect of SSO |
|---|---|
| Password reuse across services | Mitigated — there is no per-application password |
| Orphaned accounts after departure | Partly — login is blocked, but only SCIM removes the account |
| Weak or shared credentials | Mitigated — policy is enforced centrally |
| Phishing of the identity provider itself | Unaffected, and the blast radius is now every application |
| Session or token theft after sign-in | Unaffected |
| An authorised user doing something harmful | Unaffected — this is an audit-log problem |
The middle rows are the ones that matter for a comms platform. Whether someone signed in with SAML or a link in their inbox, the control that answers "who sent that message to 4,000 families" is a tamper-evident audit log, not the authentication method.
Where Kastr stands, stated plainly
Kastr does not implement SAML, OIDC, Google or Microsoft sign-in, Clever or ClassLink login, or MFA of any kind. A magic link is the only authentication mechanism we ship. If SSO is a scored requirement in your RFP, we lose that row, and we would rather you knew now.
What the magic link actually is, so you can judge it rather than take a label: a 32-byte random token, single-use, valid for 15 minutes, consumed atomically so that a prefetching mail scanner cannot burn it and a replay cannot reuse it. The link is bound to the device that requested it by comparing a SHA-256 cookie with timingSafeEqual. A token is issued whether or not the email address exists, so the endpoint cannot be used to enumerate accounts. Session IP addresses are stored hashed, never raw.
For guardians, that is a stronger position than most alternatives: there is no password to reuse, no credential database to breach, and no shared family login circulating on a group chat. For staff at a district that has standardised on Entra and expects every vendor to federate, it is a real gap. Both of those are true at once, and a vendor telling you only the first half is selling.
Questions people actually ask
Do parents and guardians need SSO?
Almost never. Guardians have no district-issued identity to federate, so offering them SSO means creating a consumer identity system with its own password resets and breach surface. Possession-based sign-in through email or SMS is the normal and generally safer answer for that population.
What is the difference between SSO and SAML?
SSO is the outcome — sign in once, reach many applications. SAML is one protocol for achieving it, and OpenID Connect is the more modern alternative. A district asking for SSO is usually asking for SAML or OIDC specifically; it is worth confirming which.
Is a magic link less secure than SSO?
Different, not strictly weaker. A magic link proves control of a mailbox at that moment; there is no password to reuse or phish. It inherits the security of the email account, and it does not give a district central session revocation. For staff at a federated district, SSO is better. For guardians with no district identity, a link is usually the more defensible design.
Can a district require SSO for a communications platform?
Districts do require it, and often score it in an RFP. It is worth asking which population the requirement covers. Requiring staff SSO is reasonable and common; extending the same requirement to guardians usually reflects a template rather than a decision, and it excludes designs that are safer for parents.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.