Google Workspace for Education with Kastr: staff directory sync, and why there is no Google Sign-In

The bottom row is the honest summary: this is not a menu. Magic link is the only authentication Kastr has. The table exists because the trade-off is real and worth arguing about, not because we are pretending to have made a considered selection from three shipped options.

Using Google as your staff directory source

Google Workspace knows who works for your district and, if your organisational-unit tree is maintained, roughly where. That makes it a reasonable staff source and a hopeless student-and-guardian source, guardians do not have district Google accounts, and student accounts carry no contact information for their families.

So the topology is: staff from Google, students and guardians from the SIS. Two files, one endpoint.

For the staff extract, use the Admin SDK Directory API and pull active accounts only, with the fields that matter: primary email, given and family names, organisational unit path, suspended status, and whatever custom schema your district uses to hold a role or building code. Filter out suspended accounts, a suspended account is a person who should not be receiving staff broadcasts.

A worked example of how the OU path can drive your job in a three-building district. A roster entry carries only a role of student, guardian or teacher, with no building or permission, so the OU path decides who is sent and as what:

• /Staff/Lincoln Elementary/Teachers → teacher entries.
• /Staff/Lincoln Elementary/Office → not a roster role. Front-office staff are usually the people who send messages, and that permission is not something a roster entry carries.
• /Staff/District Office → likewise not a roster role; district-level access is not set by a roster entry.

Filtering suspended accounts matters for a second reason: anyone who drops out of the batch is withdrawn by the next sync, which is exactly what should happen when someone leaves.

Groups are not roles

The tempting shortcut is to use Google Groups as audiences: you already have all-staff@, lincoln-teachers@, and a dozen others, and they are more or less maintained.

Two reasons not to build on them. First, group membership carries no dates. A group tells you who is in it right now and nothing about when they joined or left, so it cannot answer a question about the past, and roster questions are almost always about the past when they are being asked seriously. Second, groups drift. Every district has at least one distribution list that has not been accurate since 2021 and that nobody owns.

Use the OU path, which is maintained because account provisioning depends on it, and treat groups as a cross-check rather than a source. To answer the related question directly: Kastr cannot send to a Google Group as an address. Messages go to people in the roster, on the contact points the roster gave us, which is what makes per-person consent state, language preference and delivery evidence possible at all.

Why there is no Google Sign-In, stated plainly

Kastr supports no SSO. No SAML, no OIDC, no Google Sign-In, no ClassLink, no Clever, and no MFA of any kind. Magic link is the only authentication path in the product, for a district superintendent and for a guardian alike.

The reasoning: in a 12,000-student district there are roughly 20,000 guardians and 900 staff. Guardians hold no district-issued account and never will. An authentication design that works beautifully for 4% of the people the system serves, and requires a second mechanism for the other 96%, means running two authentication systems, and the weaker one still exists. We built one path and made it as strong as a single-factor path can be.

Where that costs you. Staff sign in through their email rather than through the portal they already have open, which is real daily friction. There is no MFA to show a security reviewer. There is no immediate central offboarding kill switch of the kind an identity provider gives you, ending a role stops the next sign-in, but it is not the same control. If your district has a policy mandating SSO for all vendor systems, Kastr does not meet it today. That is a legitimate reason to choose someone else and we would rather you knew in August than in March.

What a security reviewer should test instead

The magic link design is specific enough to be tested in ten minutes, which is more than can be said for most vendor security claims. Hand your reviewer this list:

• Single use. Request a link, open it, then open it again. The second attempt must fail. Consumption is atomic, which also defeats the mail-scanner prefetch problem where a security appliance opens the link before the human does.
• Fifteen-minute expiry. Request a link, wait, then use it. Tokens are 32 random bytes with a hard time-to-live.
• Same-device binding. Request on one browser, open in another. It must fail. The binding is a cookie holding the SHA-256 of the token, compared with a constant-time comparison.
• No account enumeration. Request a link for an address that does not exist. The response must be identical to the one for a real address, in both content and timing.
• Session records. Confirm that the stored session IP is a hash rather than the address itself.

Alongside that, the parts a reviewer usually cares about more: tenant isolation is enforced by Postgres row-level security under a non-owner, DML-only role, is hierarchy-aware, fails closed with no organisation context, and is covered by a cross-tenant leakage suite that runs in CI against real Postgres 16. Every administrative action lands in a per-organisation SHA-256 hash-chained audit log that is append-only at two independent layers, revoked table permissions and RLS policies with no UPDATE or DELETE path.

Questions people actually ask

Related