Identity & SSO (procurement)
Last updated 2026-06-08
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
Single Sign-On (SSO)
Configure SSO so users sign in with their existing district identity (Google Workspace, Microsoft Entra ID, Okta, or generic SAML 2.0). Google Workspace — OIDC, the simplest…
Security overview
Who uses it: District IT and security reviewers. Purpose: One page summary of AmplifyED's security posture for procurement. US based managed cloud hosting. Single tenant database…
