SAML 2.0 single sign-on. Self-serve in 10 minutes, on Pro and above.

Wengrow supports SAML 2.0 single sign-on on the Pro, Business, and Business+ plans. Configure your identity provider — Okta, Microsoft Entra, Google Workspace, OneLogin, JumpCloud, or any SAML 2.0–compliant IdP — in about 10 minutes using a self-serve flow inside the admin panel. Domain ownership is verified via a DNS TXT record before SSO activates. Once active, every user on your verified domain routes through your IdP, with MFA delegated to your identity provider and every sign-in recorded in your workspace's audit log. JIT user provisioning is supported today. SCIM provisioning and IdP-initiated flow are on the roadmap — called out below.

How Wengrow SSO works

Three steps, each a few minutes:

1. Paste three identifiers into your IdP. Create a SAML 2.0 application in Okta, Entra, or Google Workspace and paste Wengrow's ACS URL, Entity ID, and Metadata URL from Settings → SSO.
2. Verify your domain with one DNS TXT record. Wengrow gives you the host and value; add it at Cloudflare, Route 53, GoDaddy, or wherever your DNS lives. Most registrars propagate in under a minute.
3. That's it — SSO is enforced. Everyone on your verified domain routes through your IdP. Non-SSO sign-in paths (password, magic link, Google OAuth) are blocked at the API layer for users on that domain.

See the full 10-minute walkthrough for Okta, Entra, and Google Workspace — with screenshots, DNS examples, and rotation instructions.

Security model

• Domain ownership is required. No one claims a domain they don't control — DNS TXT verification is mandatory before a domain activates. Without it, a malicious tenant could register @google.com and hijack every Gmail user's login.
• Domain exclusivity is enforced. A given email domain routes to one Wengrow workspace globally — not one per region, not one per plan, one period.
• SSO is enforced, not optional. Once a domain is verified and SSO is active, all non-SSO sign-in paths (password, magic link, Google OAuth) are blocked for users on that domain. Defense in depth at the API layer, not just the login UI.
• Service-role separation. Wengrow's API is the only process that holds admin credentials for your SSO provider. Your IdP secrets never touch browser code.
• Tamper-resistant audit log. Write-only from the application layer, with row-level security denying all external reads. The same RLS model governs every tenant in Wengrow — see our full security posture.

Your audit log

• What's recorded, per event: actor (user ID + email), IP address, UTC timestamp, event type, target resource, and a structured JSON details payload. Applies to every SSO configuration change, every SSO sign-in (not just first login), MFA delegation, bypass attempts, forced sign-outs, and automatic 30-day downgrade cleanup.

• Who uses it, and how: it's your workspace's audit log, not ours. Scoped to your tenant, write-only from the application layer, with row-level security denying all external reads. Accessible to workspace admins from the admin panel. Retained for the life of your subscription so your compliance team can reconstruct any session after the fact.

• What this is not: not SOC 2 certified today. Wengrow is working toward SOC 2 Type I in 2026 and Type II after; the audit log's field coverage and tamper-resistance are designed to support that future audit, but the controls are documented-not-audited right now. If you need SOC 2 today, we're not your vendor. ^[src]

On the roadmap, said plainly

SCIM provisioning and deprovisioning

Not in the current release. JIT provisioning handles creation (a user signs in via SSO for the first time; Wengrow creates their profile and tenant membership). Deprovisioning is handled by deactivating the user in your IdP plus "Revoke all SSO sessions" in Wengrow when you need immediate session invalidation.

SCIM is a roadmap item. If your procurement requires SCIM push-provisioning today, we're not your vendor yet — let us know and we can tell you when we expect to ship it.

IdP-initiated SSO

SP-initiated only in the current release. Users start from app.wengrow.app/login rather than from an Okta dashboard tile. IdP-initiated flow is on the roadmap.