What are the SSO options for student logins in K-12?

The protocols, briefly and practically

SAML 2.0 is the older standard and remains the most widely supported in education software. The district runs an identity provider, the application is a service provider, and they exchange a signed XML assertion asserting who the user is. Setup involves trading metadata: an entity ID, a sign-in URL, and a signing certificate on each side. It is fiddly to configure the first time and stable thereafter.

OIDC — OpenID Connect, built on OAuth 2.0 — is the newer approach and simpler to work with. It uses JSON web tokens over HTTPS instead of XML, integrates naturally with mobile and single-page applications, and has fewer moving parts. Newer vendors tend to support it; older education vendors often do not.

When an application supports both, choose OIDC. When it supports neither and offers only its own username and password, you have a decision to make about whether it is worth adopting, because every application with independent credentials is a set of passwords students will forget and staff will reuse.

A third pattern worth naming: link-style SSO, where the portal simply deep-links into an application that authenticates the user through Google or Microsoft anyway. It is not really a protocol integration, but for the many applications that already accept Sign in with Google, it delivers the actual user experience — one click from the portal into a working session — with almost no configuration.

Choosing your identity provider

If the district runs Google Workspace for Education, Google can act as the identity provider for SAML and OIDC applications, and student Chromebooks sign in with it natively. This is the path of least resistance for most K-12 districts, and for a Chromebook-centric district it is usually correct.

If the district is Microsoft-centric, Entra ID plays the same role, with the advantage that staff Windows devices and Microsoft 365 come along for free. Districts frequently run both — students on Google, staff on Microsoft — which works but means two directories to keep in sync with the SIS.

A dedicated district identity provider is worth considering when neither of those fits well. The specific cases: you need authentication methods Google and Microsoft do not offer, like badge scanning or picture passwords for young students; you want a single launcher portal that spans applications from both ecosystems; or you want authentication that survives a change of email provider.

Whatever you choose, the roster connection is what makes it work. Accounts should be created, updated, and deactivated from your SIS data, not maintained by hand. The most common identity failure in a district is not a protocol problem — it is a student who withdrew in November still having an active account in April.

Two-factor for staff, particularly for anyone with administrative access, is not optional anymore. Education is a heavily targeted sector and administrator credential compromise is the common entry point. TOTP through an authenticator app is the baseline and costs nothing.

Logins for students who cannot type a password

A kindergartener cannot type a twelve-character password, and requiring one produces the predictable workaround: a taped list of credentials on the classroom wall, which is worse security than any alternative discussed here. The realistic options are badge scanning and picture passwords.

QR or barcode badges work like this: each student has a card, a lanyard tag, or a sticker on their device or desk with a code that identifies them. They hold it up to the device's camera or a small scanner and are signed in. The whole class is logged in inside a couple of minutes, and no instructional time is lost to typing. The tradeoff is physical: a badge is a bearer credential, so anyone holding it can sign in as that student.

Picture passwords have students select a sequence of images — three animals in order, say — instead of typing characters. Children handle this well, it requires no physical object to lose, and it does not depend on a camera. It is somewhat slower than a badge and somewhat more resistant to casual sharing.

Both should be scoped tightly. Restrict them to the grade levels that need them, and consider restricting them to on-network use or to specific device sets. A badge credential that works from a home computer is a different risk than one that only works on a classroom Chromebook.

Have a plan for lost badges, because you will reprint many of them. The process should be a teacher or office staff action, not a help desk ticket, or the friction will push classrooms back to shared passwords. And rotate the underlying code when a badge is reissued rather than reprinting the same one, so a found badge stops working.

The launcher portal

Even with SSO working, students need one place to start. A launcher portal — a page of tiles, one per application, showing only what that student should see — is what turns a set of integrations into a usable experience.

Scope tiles by role and by grade. A third grader should not see the tile for the high school's math platform, and staff applications should not be visible to students at all. Driving this from roster data means it stays correct without anyone maintaining lists.

Mix the integration types on the same page. Some tiles will be full SAML or OIDC handoffs, some will be plain deep links into applications that authenticate through Google anyway, and both look identical to the student. That is the point: the portal's job is to be the one bookmark, not to be architecturally pure.

Make it work on the devices students actually use. For Chromebook districts, this means the portal is a web page that can be set as the managed homepage or pinned via policy; students should land on it when they open the machine rather than having to find it.

For staff, the portal is also where you put the things people ask about constantly — the help desk link, the device agreement, the password reset path. A single well-known page reduces the ambient support load noticeably.

Privacy and the questions parents ask

Student identity data is education records, and the usual rules apply. FERPA governs disclosure of personally identifiable information from education records, and directory information exceptions are narrower than districts sometimes assume. COPPA is relevant when applications collect data from children under thirteen, and the school-consent pathway has conditions attached. Many states add their own student data privacy statutes with stricter terms, and some require specific contract language with vendors.

SSO actually helps here, because it reduces the number of vendors holding student credentials and centralizes the record of who has access to what. When an application authenticates through your identity provider, it does not store a student password, and revoking access is one action in one place rather than an email to a vendor.

Be deliberate about what attributes you release to each application. The default temptation is to send everything — name, email, grade, school, student ID — because it makes setup easier. Send the minimum the application actually needs, and document what each one receives. This document is what you will want when a parent or a board member asks.

Biometrics deserve a specific warning: several states regulate biometric identifiers separately and strictly, and some prohibit their use with students outright. Face or fingerprint login for students is a legal question before it is a technical one, which is part of why badges and picture passwords remain the standard answer for young learners.