SSO setup

Why SSO for Red Stet

Password sign-in works for an individual teacher. A district needs more: IT owns identity for thousands of accounts, compliance needs an answer for FERPA and CIPA, principals want students landing in Red Stet from the same place they land everywhere else.

SSO solves three problems. Security — one source of credentials, central revoke, no student or teacher password in our database. Compliance — your DPA covers the identity layer because the IdP is yours. Rostering — pair SSO with an LMS launch and the roster comes with it.

LMS integration covers a related path: direct LTI 1.3 launch from Canvas, Schoology, or Brightspace. SSO sits one layer below — even an LTI launch resolves "this user in the LMS" to "this account in Red Stet," and SSO makes that resolution durable.

Clerk as the identity provider auth.config.ts

Red Stet uses Clerk for every account — student, teacher, admin, verifier. Convex trusts Clerk-issued JWTs and looks up the user via the token's tokenIdentifier claim.

Configuring SSO connects your IdP (Google or Microsoft) to our Clerk tenant — not directly to Red Stet. Clerk handles OIDC, JWKS rotation, and the session cookie. Convex sees a verified identity and binds it to a users row on first sign-in.

You won't log into the Clerk dashboard — we do that during onboarding. Matters for troubleshooting: every failure below traces to "Clerk says X" or "Convex says Y."

Google Workspace setup

The most common K-12 IdP in the US and the simplest configuration. No Google-side provisioning — Clerk has Google as a pre-built OAuth client.

What we need from you

1. Your school's primary email domain(s). Usually one (centralhs.edu); sometimes multiple (a district running district.k12.us for staff and students.district.k12.us for students).
2. One administrator email for the rollout.

What happens next

"Continue with Google" accepts your users immediately — no Google Workspace admin action needed for the basic flow.

For tighter control, your Google admin restricts OAuth consent via Apps > Google Workspace Marketplace > Apps list — the right move for districts that don't want students approving third-party apps on their own.

Microsoft 365 / Entra ID setup

The common IdP in higher ed and Windows-first K-12 districts. Same shape as Google — Clerk-mediated OAuth — with more knobs on the tenant side.

Multi-tenant vs single-tenant

Clerk's Microsoft connection is multi-tenant by default — any Microsoft account from any tenant can complete the OAuth flow.

If your tenant requires third-party apps to be registered in Entra ID > Enterprise applications before consent, your admin adds Red Stet (the Clerk OAuth app) once. We provide the redirect URIs.

Group claims and roles

Microsoft tokens can carry group memberships and role assignments. Red Stet consumes these for auto-verify (see Provider configuration & auto-verify) — when a user's group claim matches an org's autoVerifyGroups entry, teacherStatus flips to verified.

Provisioning & de-provisioning

Every IT director asks: what happens when a student transfers, a teacher leaves, or an account is disabled in our IdP?

Provisioning

Just-in-time: a user row is created on first sign-in. Until then, the user doesn't exist in our system.

De-provisioning

Disabling a user in your IdP — graduation, transfer, termination — immediately blocks sign-in. The IdP refuses the OAuth flow; Clerk can't mint a token; Convex never sees them.

The Red Stet account row stays. It anchors past submissions, grades, recordings, and the provenance chain on work the student did before leaving.

Deletion on request

FERPA, COPPA, GDPR deletion rights run as a separate operation. See the privacy notice for the retention schedule.

SSO and teacher verification teacherStatus

SSO answers "who is this user." It doesn't answer "is this user a teacher?" — and the teacher / student distinction is load-bearing because teachers create assignments and see other people's writing.

Self-serve teacher signup

A new account from any IdP starts as a student. To become a teacher, they apply via the in-app signup — a school ID photo or credential upload, reviewed within 1–2 business days.

Org admins skip this for known-good groups: see Provider configuration & auto-verify for group-claim and OU-claim auto-verification, and school-account for domain-based auto-verify.

Troubleshooting sign-in failures

"I can't sign in" is almost always one of three patterns. Walk through them in order before escalating.

1. Wrong account linked

Common with shared family devices — a parent's Google account is the browser default. Symptom: wrong name after sign-in. Fix: sign out of Red Stet, sign out of Google/Microsoft, retry. The IdP's account chooser appears.

2. Pending teacher status

Teacher signed in but lands in student view. Symptom: student view despite a teacher application filed. Fix: verification queue, not sign-in. Check teacherApplications and approve or reject.

3. Stale Clerk session

Infinite redirect loop or "session expired" right after sign-in. Symptom: after a browser update or long idle. Fix: clear cookies for the Red Stet domain, retry. If it persists across browsers, escalate — token-rotation issue on our side.

Related & feedback

→ School account setup — the broader district onboarding flow.

→ Connecting Red Stet to your LMS — LTI 1.3 launch from Canvas, Schoology, Brightspace, or Google Classroom. Often paired with SSO; sometimes a substitute.

→ Back to the help library.

Hit a setup snag? Email feedback.