---
title: Identity & SSO (procurement)
category: procurement
order: 7
lastUpdated: 2026-06-08
featureAvailability: GA
roles: [district-admin, admin]
relatedArticles: [integrations/sso, procurement/security-overview]
---

## 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

- [Single Sign-On (SSO) — operational setup](/help/integrations/sso)
- [Security overview](/help/procurement/security-overview)

## 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.