Skip to content

Set up Single Sign-On (SAML 2.0)

Available on Pro, Business, and Business+ plans.

This is the full 10-minute walkthrough. For a procurement-ready overview of Wengrow's SSO and security model, see /enterprise/sso.

SSO routes your team through your existing identity provider — Okta, Azure AD / Entra, Google Workspace, OneLogin, JumpCloud, or any SAML 2.0–compliant IdP. Once you've completed setup:

The whole setup is self-serve and takes about 10 minutes. No support ticket, no custom configuration, no phone call required.

What you'll need

The three steps

1. Open the SSO settings page

In Wengrow, navigate to Settings → SSO (it appears in the nav only when your tenant is on a qualifying plan). You'll land on a page that shows three identifiers — your ACS URL, Entity ID, and Metadata URL. Keep that tab open.

2. Configure your identity provider

Create a new SAML 2.0 application in your IdP and paste the three Wengrow-provided identifiers into your IdP's SAML app configuration. Your IdP will then hand you an IdP Metadata URL in return.

See the IdP-specific walkthroughs below for Okta, Azure AD, and Google Workspace.

3. Connect Wengrow to your IdP + verify your domain

Back in Wengrow's SSO settings:

  1. Paste your IdP Metadata URL into the form
  2. Enter your email domain(s) (e.g. acme.com)
  3. Click Create SSO connection
  4. Wengrow shows you a DNS TXT record to add to your domain — copy the host and value
  5. Add the TXT record at your DNS registrar (Cloudflare, Route 53, GoDaddy, etc.)
  6. Come back and click Check DNS record

The status pill flips to Active. Your team can now sign in with SSO.

IdP walkthroughs

Okta

  1. Okta Admin Console → Applications → Create App Integration
  2. Sign-in method: SAML 2.0 → click Next
  3. App name: Wengrow → click Next
  4. Under Configure SAML:
    • Single sign-on URL: paste your Wengrow ACS URL
    • Audience URI (SP Entity ID): paste your Wengrow Entity ID
    • Name ID format: EmailAddress
    • Application username: Email
    • Leave the other defaults
  5. Click Next → fill in feedback → Finish
  6. On the app's Sign On tab, find the Identity Provider metadata link. Right-click → Copy Link Address. This is your IdP Metadata URL for step 3 above.
  7. Under Assignments, assign the app to the people or groups who should be able to sign in.

Total time in Okta: ~3 minutes.

Azure AD / Microsoft Entra

  1. Azure Portal → Microsoft Entra ID → Enterprise applications → New application
  2. Click Create your own application → name it "Wengrow" → choose Integrate any other application you don't find in the gallery → Create
  3. Under Set up single sign on → choose SAML
  4. Basic SAML Configuration → Edit:
    • Identifier (Entity ID): paste your Wengrow Entity ID
    • Reply URL (Assertion Consumer Service URL): paste your Wengrow ACS URL
    • Save
  5. In section 3 (SAML Certificates), copy the App Federation Metadata URL. This is your IdP Metadata URL for step 3 above.
  6. Under Users and groups, assign your team.

Total time in Entra: ~4 minutes.

Google Workspace

  1. Google Admin Console → Apps → Web and mobile apps → Add app → Add custom SAML app
  2. App name: Wengrow → Continue
  3. Copy the SSO URL and Entity ID from Google — you'll need these, but first let Google generate your IdP configuration
  4. On the Google Identity Provider details page, click the Download Metadata link to get an XML file — open it, copy the full contents. (Google Workspace doesn't expose a metadata URL, so you'll paste the XML instead.)
  5. Continue
  6. On the Service provider details page:
    • ACS URL: paste your Wengrow ACS URL
    • Entity ID: paste your Wengrow Entity ID
    • Name ID format: EMAIL
    • Name ID: Basic Information → Primary email
  7. Continue → skip attribute mapping (not required) → Finish
  8. Turn the app ON for everyone (or the OU you want).

Back in Wengrow, use the Metadata XML tab instead of URL and paste the XML you copied in step 4.

Total time in Google Workspace: ~5 minutes.

Verify your email domain

Wengrow requires DNS TXT verification before activating SSO on a domain. This prevents any organization from claiming a domain they don't control — without it, a malicious tenant could register @google.com and hijack every Gmail user's login. Your DNS record is the proof of ownership.

The record Wengrow gives you looks like this:

FieldExample
TypeTXT
Host / Name_wengrow-sso (or _wengrow-sso.acme.com depending on your registrar)
Valuewengrow-sso-verify=7e48683f06d739decfbe…
TTLDefault / automatic

Adding the record at common registrars

Come back to Wengrow and click Check DNS record. If it fails the first time, wait 60 seconds and retry — some registrars take a minute to propagate.

Once verified, the provider flips to Active and your team is live.

What your team experiences

Once SSO is active on your domain, here's what a typical sign-in looks like from your employee's perspective:

  1. They visit app.wengrow.app/login
  2. They type their work email (e.g. jane@acme.com)
  3. Within half a second, the sign-in form changes: the password field disappears, a Continue with SSO button appears with the helper text "Your organization uses Single Sign-On"
  4. They click Continue with SSO
  5. They're redirected to your IdP (Okta, Entra, etc.). If they're already signed in there, they're redirected back to Wengrow instantly. If not, they sign in using their IdP credentials + whatever MFA your IdP enforces.
  6. They land on the Wengrow dashboard, automatically provisioned as a member of your workspace.

For first-time users, you don't need to pre-provision accounts in Wengrow. When a new employee signs in via SSO for the first time, Wengrow creates their user_profile and tenant membership automatically. Just assign them to the Wengrow app in your IdP and they're good.

Multi-Factor Authentication

Your IdP owns MFA. Wengrow delegates the MFA contract entirely to your identity provider. If you require MFA in Okta / Entra / Google, your team will see their familiar MFA prompt (TOTP app, hardware key, push notification, etc.) when they sign in to Wengrow.

Wengrow logs every SSO sign-in with a sso.login_mfa_delegated audit event, so you have a clean audit record that MFA enforcement was handled upstream.

Ongoing management

Rotating certificates

Your IdP will rotate its SAML signing certificate every 12–36 months. As long as you configured Wengrow with your IdP's metadata URL (not a pasted XML), rotations propagate automatically — Wengrow re-reads the metadata on a schedule. No action required.

If you used the XML tab, you'll need to paste the new XML when your IdP rotates. Wengrow sends a reminder email 30 days before expiry to the tenant owner.

Adding more domains

Need to add a subsidiary or a secondary domain? On the SSO settings page, click Add domain, enter it, and verify it with another TXT record. Multiple domains can route to the same SSO connection.

Forcing sign-out

Click Revoke all SSO sessions on the SSO settings page. Every signed-in SSO user in your workspace gets signed out immediately. Use this after a security incident, employee offboarding wave, or any time you need a clean slate. Revokes are audited.

Disabling SSO temporarily

Click Delete SSO connection to remove the SAML provider. Note: this signs out every current SSO user. Use it only if you're migrating IdPs or deliberately switching off SSO.

If you downgrade to a non-SSO plan

Wengrow keeps your SSO configuration in place for 30 days. During that window:

After 30 days, the provider is permanently deleted and you'd start from scratch if you re-upgraded.

Your audit log

Security model at a glance

FAQ

Do my users need to create passwords for Wengrow? No. Once SSO is active on your domain, users can't create passwords. Sign-in is SSO-only.

What happens when someone leaves our company? Deactivate them in your IdP. Their next Wengrow request — whether a live session or a new sign-in attempt — will fail at the IdP level, and Wengrow won't issue a new session. For immediate session invalidation, click Revoke all SSO sessions in Wengrow.

Can we use SSO for some users and passwords for others? Not on the same verified domain. Once a domain is SSO-enforced, every user on that domain must sign in via SSO. If you have users on a non-enforced domain (e.g. contractors on a personal email), they can still use password / Google / magic-link sign-in normally.

What SAML NameID formats do you support? emailAddress (preferred) and persistent. Most IdPs default to one of these.

Does Wengrow support IdP-initiated SSO? SP-initiated only in the current release. (A user has to start from app.wengrow.app/login rather than from an Okta dashboard tile.) IdP-initiated flow is on the roadmap — let us know if you need it.

Does Wengrow support SCIM provisioning and deprovisioning? Not in the current release. Wengrow does JIT provisioning (users are auto-created on first sign-in), and you can manually invalidate access via Revoke all SSO sessions plus deactivating the user in your IdP. SCIM is on the roadmap — contact us if you need it.

What's your SAML response validation policy? Signature validation is enforced. Response freshness (InResponseTo + NotOnOrAfter) is validated. Replay protection is enforced. Unsigned assertions are rejected.

What if my IdP's metadata URL requires IP allowlisting? Wengrow fetches IdP metadata from our backend — the public Wengrow egress IPs are published on our trust page. Allowlist those in your IdP's metadata endpoint restrictions.

How do I export the audit log? From the admin panel — workspace admins can filter by event type (e.g. sso.*) and export to CSV or JSON. If you need periodic push into your SIEM (Splunk, Datadog, etc.), that's available on enterprise contracts; contact us.

Need help?

SSO setup is designed to be self-serve, but if you hit a wall:

Include the following in any support ticket:

We can typically unblock SAML configuration issues in under an hour during business hours.

Related reading