Identity & SSO (procurement)

Last updated 2026-06-08

View raw markdown

At a glance

  • Who uses it: District IT and identity team reviewing AmplifyED for procurement.
  • Purpose: Summarize supported identity options, MFA posture, and provisioning behavior.

Supported

  • OIDC — Google Workspace, Microsoft Entra ID.
  • SAML 2.0 — Okta, OneLogin, ADFS, generic IdP.
  • Email + password — bcrypt-hashed, with account lockout after 3 failed attempts.

Domain verification

Districts add their email domains and verify ownership via a DNS TXT record (_amplifyed-verify.<domain>). Once verified:

  • Sign-ins from that domain are routed to the configured IdP.
  • Just-in-time provisioning creates user records using the domain's default_sso_role.

Just-in-time provisioning

New users who sign in via a verified domain are provisioned automatically with the default_sso_role for that domain (typically teacher or facilitator). Admin-level roles are never auto-granted via JIT — they require explicit assignment by an existing org admin (or, for cross-org changes, super-admin approval).

SCIM

SCIM 2.0 deprovisioning is on the roadmap. Today, deprovisioning happens via IdP-driven session invalidation (sessions terminate within minutes of IdP logout/disable) and via direct admin deactivation in Administration → Users.

MFA

MFA is enforced by your IdP — AmplifyED honors whatever MFA policy your IdP requires (TOTP, push, hardware keys, conditional access). For email + password sign-in, MFA is on the roadmap; districts requiring MFA today should enable SSO.

Session security

  • HTTP-only session cookies.
  • Tokens rotate on sign-in.
  • Configurable session length per org (default: 12 hours).
  • Idle timeout (default: 30 minutes) with re-authentication prompt.

Brute-force protection

After 3 consecutive failed sign-ins, the account is locked for a cooldown period. Lockouts are recorded in the audit log. Admins can clear a lockout manually if needed.

Related articles

FAQ

Do you support custom claims in SAML / OIDC? Yes — claims can be mapped to AmplifyED roles during onboarding.

Can we lock sign-in to our IdP only? Yes. Once a domain is verified and SSO is enforced, email + password sign-in is blocked for that domain.

Related