Jordan: So I'm on a Zoom with a VP of Operations at a logistics company — forty-person outfit, solid budget, they need a client portal for their carriers. I've already scoped the build. Softr front end, Airtable backend, a couple Make scenarios handling the data sync. Clean project. Maybe eight thousand dollars, three-week delivery. And we're twenty minutes into the call, everything's going well, and she says — almost as an aside — "Oh, and it needs to work with our Okta."
Just like that. "It needs to work with our Okta." Like she's asking if it comes in blue.
And I froze. Because I didn't know if Softr could do that. I knew it had user authentication. I knew it had login pages. But SAML? OIDC? Enterprise single sign-on with an identity provider I'd never wired up to a no-code tool? I had no idea.
So I did what you do when you don't know the answer on a sales call. I said, "Absolutely, we support SSO integration — let me send over the technical spec for that piece separately." Bought myself forty-eight hours.
And then I spent those forty-eight hours in a mild panic. Reading Softr docs at midnight. Googling "Softr SAML" and getting back mostly their own help pages and nothing else. Trying to figure out if I needed to build a custom auth layer, or if there was some middleware I was missing, or if the whole deal was about to fall apart over four letters — S, S, O.
It didn't fall apart. I shipped SSO on that portal in under a day. But only because I stumbled into the right combination of tools — and I want to make sure you don't have to stumble.
Jordan: Imagine you just landed a mid-market client — maybe a regional healthcare group, maybe a manufacturing company with eighty employees — and they want a portal. You can build it. You know you can build it. But somewhere in the procurement thread, their IT director drops the requirement: "All vendor tools must support single sign-on through our identity provider." And suddenly you're not sure if the deal is yours to win.
Today I'm walking through exactly how I wired SAML and OIDC single sign-on into a Softr portal using a hosted identity provider — Auth0 and Clerk are both on the table — with a passwordless fallback that stays live during the pilot and a rollback plan you can execute in under five minutes. I'll also cover what's different if you're building on Glide or Retool. I'm Jordan. This is Headcount Zero.
Jordan: Okay, so first — the thing that would have saved me that midnight panic session. Softr supports SSO natively. Both SAML and OpenID Connect. It's right there in their docs. The OIDC setup explicitly requires their Enterprise plan. The SAML docs don't state the plan gate as clearly — the configuration pages walk you through it without specifying which tier — but in practice, you're looking at Enterprise for either protocol. So before you promise SSO to a client, confirm you're on that plan or factor the upgrade into your project pricing.
That's step zero. Don't quote SSO on a Business plan and find out later.
Now, the real question is — do you wire SSO directly between the client's identity provider and Softr, or do you put a hosted IdP in the middle? And this is where I want to save you a decision that took me way too long.
If your client runs Okta, or Microsoft Entra ID — which used to be Azure AD — or Google Workspace, you could technically configure a direct SAML connection between their IdP and Softr. Softr's docs walk through the Azure AD setup step by step. You grab the Audience slash Entity ID and the ACS URL from your Softr app, plug those into the enterprise application on the Entra side, upload the IdP metadata XML back into Softr, map your attributes — email, first name, last name — and you're live.
That works. For one client. With one IdP. On one portal.
But here's where it gets complicated. What happens when client number two uses Okta instead of Entra? And client three is on Google Workspace? Now you're managing three different SAML configurations, three different certificate expiry dates, three different metadata files. And you're doing it inside Softr's admin panel, which is not built to be an identity management dashboard.
So the move — the one I landed on and haven't looked back from — is to put a hosted identity provider between your clients and your portal. Auth0 or Clerk. They become your single auth layer. Every client's IdP federates into Auth0 or Clerk, and Auth0 or Clerk federates into Softr. One connection on the Softr side. Many connections on the IdP side. Clean.
Jordan: Let's talk cost, because this is where you're going to scope your proposal. Auth0's free tier gives you twenty-five thousand monthly active users and — as of their current pricing page — one enterprise connection. That means one client's IdP federated in at zero cost. They also have a startup program that bumps you to a hundred thousand MAU with access to enterprise identity providers for a year. Worth applying if you qualify.
Clerk takes a different approach. Fifty thousand monthly retained users free. A hundred monthly retained organizations free. And on their Pro or Business plan, you get one enterprise SSO connection per app included. Need more? They bill on a tiered schedule — starts at seventy-five dollars per additional connection and drops to fifteen as you scale up.
So the math for your first SSO client is basically... free. On either platform. The cost only matters when you're managing multiple enterprise connections, and by that point you should be pricing SSO as a line item in your enterprise tier anyway.
One more thing on Clerk specifically — they support custom session durations up to ten years, and they have this feature called Satellite Domains that lets you share sessions across different domains for ten dollars a month each. If you're building portals on custom subdomains for each client, that matters for persistence.
Jordan: Alright, the actual build. I'm going to walk through SAML on Softr because that's what most enterprise IdPs default to, and it's where the gotchas live.
You need two values from your Softr app — the Audience, which is also called the Entity ID, and the Reply URL, which is the ACS URL. ACS stands for Assertion Consumer Service. That's the endpoint where the IdP sends the authentication response after the user logs in on their side. You copy both of those from Softr's SSO settings.
Then you go to your hosted IdP — let's say Auth0 — create an enterprise connection, choose SAML, and paste in those two values. On the other side, you take the IdP metadata XML that Auth0 generates and upload it into Softr.
And this is where I burned an hour on my first attempt. The ACS URL has to match exactly. Not almost. Not close. Exactly. If there's a trailing slash mismatch, if the protocol says H-T-T-P instead of H-T-T-P-S, if there's a case difference in the path — the assertion fails silently. You get a generic login error and no useful debug information from Softr's side.
The fix is boring but critical. Copy-paste both values. Don't type them. Don't edit them. Copy from Softr, paste into Auth0. Copy from Auth0, paste into Softr. Then verify character-for-character before you test.
Attribute mapping is the next step. You need email — that's your user identifier. First name and last name for the profile. Softr's SAML docs show the exact attribute keys they expect. Map those in your IdP's enterprise connection settings and you're wired.
Now — OIDC is actually simpler if your client's IdP supports it. Softr's OpenID Connect setup takes a provider URL, a client ID, a client secret, and a callback URL. When a user authenticates through OIDC for the first time, Softr auto-creates a user record. That's JIT provisioning — just-in-time — and it means you don't have to pre-load user accounts. They show up on first login.
Jordan: Okay, you've wired the connection. Do not — I repeat, do not — flip the switch to SSO-only and walk away. You need to test two flows and validate three things before this goes live.
Flow one — SP-initiated. That means the user starts at your Softr portal's login page, clicks sign in, gets redirected to the IdP, authenticates, and comes back with a session. This is the flow your users will hit ninety percent of the time.
Flow two — IdP-initiated. The user clicks your app's tile inside their Okta dashboard or their Entra portal. This flow skips your login page entirely. The IdP sends the assertion directly. You need to make sure the relay state lands users in the right place inside your app — not on a blank page, not on an error screen.
I've seen IdP-initiated flows dump users onto a four-oh-four because the relay state URL wasn't configured. Test it.
The three things you validate — role mapping is correct, so users land with the right permissions. Session duration behaves the way you agreed with the client — Softr has an idle-session timeout setting that can log people out faster than they expect. And logout actually works — the user clicks sign out, the session clears, and they can't hit the back button to get back in.
If you're building on Glide instead of Softr, their SSO Dashboard is genuinely useful here. It exposes the full SAML request and response, so when something fails, you can see exactly which field didn't match. Cert mismatch, wrong Audience, bad ACS — it's all visible. Retool gives you session duration controls and the ability to enforce SSO-only login, plus they support OIDC role mapping and SAML group sync for permissions.
Glide also has a nice pattern — you configure SSO once at the team level and then enable it per-app with a toggle. So during your pilot, you can have SSO active on the staging app and off on production until you're confident.
Jordan: Here's the part most people skip, and it's the part that matters most during the first two weeks. Keep your fallback auth method live. On Softr, that means leaving email or magic-link login enabled alongside SSO. On Glide, SSO runs alongside PIN and Google sign-in until you explicitly disable them. On Retool, you can use separate spaces to maintain dual auth paths.
Why? Because during the pilot, things will break. The client's IT team will rotate a certificate without telling you. Someone will fat-finger a metadata URL. A user will try to log in from a personal device that isn't enrolled in the IdP. If SSO is the only way in and it fails, your portal is a locked door. Your client calls you. Your credibility takes a hit.
But if magic-link login is still active, you send the affected user a one-time link, they're in, and you fix the SSO issue on your timeline instead of theirs.
Document the rollback. Write down exactly how to revert to pre-SSO auth in under five minutes. Which toggles to flip, which settings to restore, which users to notify. Keep screenshots of your pre-SSO configuration. This isn't paranoia — it's the difference between a smooth pilot and a fire drill.
Jordan: Now — I want to be honest about when you should not do any of this. If your client's requirement is "Sign in with Google" — that's not enterprise SSO. That's social login. Softr supports that natively on lower plans. Don't upsell a hosted IdP and an Enterprise plan upgrade when the client just wants their team to use their Google accounts.
And the cost argument is real. Hosted IdPs add a dependency. Clerk's per-connection pricing is transparent, but if you're managing five enterprise clients with different IdPs, that's potentially several hundred dollars a month in connection fees. Auth0's free tier includes one enterprise connection, but their pricing has shifted frequently enough that I'd tell you to confirm inside your actual tenant before you put a number in a proposal.
The right move is to scope before you build. Ask the client three questions — what's your identity provider, what protocol do they require, and do they need SCIM provisioning for automated user management? If the answer is "we just want Google login," ship that and move on. If the answer is "Okta, SAML, and yes we need provisioning," now you know you're in enterprise SSO territory and you price accordingly.
Bake the IdP connection cost into your enterprise tier. Don't eat it. A seventy-five dollar per month Clerk connection is a rounding error on an eight thousand dollar portal build — but only if you've scoped it into the project from the start.
Jordan: So — back to that Zoom call. The VP who casually dropped "it needs to work with our Okta." I sent her the technical spec two days later. Auth0 as the hosted IdP, SAML federation into Softr, magic-link fallback during the pilot, a two-week test plan, and a rollback doc. She forwarded it to her IT director. He had one question — "Can we test IdP-initiated login from our Okta dashboard?" I said yes. We were live in four days.
That deal closed because I had an answer. Not because SSO is hard — it's not. But because most solo builders don't have the answer ready, and the buyer moves on to someone who does.
If you want the exact scoping checklist I use with clients now — the protocol questions, the IdP details to collect, the test flows, the rollback steps — we put the Client SSO Readiness One-Pager on the Resources page. Print it, attach it to your next SOW, and stop winging the SSO conversation.
Your one action this week — go check your Softr plan. Or your Glide plan. Or your Retool plan. Confirm whether SSO is available on your current tier. If it's not, price the upgrade. Because the next time a mid-market buyer asks about single sign-on, you want to say yes without buying yourself a panic session.
I'm Jordan. This is Headcount Zero. Go build.