Customer and Partner Portals With Single Sign On: What It Really Costs to Build

What a portal with SSO actually is once real people log in

The promise you are making is to another company's IT department: their directory is the source of truth for who gets in, and when they revoke someone, your product agrees within minutes. Everything expensive in this build follows from the second half of that sentence.

Here is where the naive version dies. You ship SAML against your first enterprise customer's Okta tenant in a week. It works, and everyone congratulates each other. Six months later that customer's IT admin offboards a sales rep on a Friday. There is no SCIM connection, so nothing tells your database anything happened. The local user row is still active, the refresh token is still valid, and your app checks its own session rather than asking Okta. He signs in Monday, exports the partner pricing sheet, and starts at a competitor on Wednesday. Nobody catches it for a quarter. It surfaces in a security questionnaire from a larger prospect, and now a six figure deal is gated on a control you cannot demonstrate.

The quieter failure is worse for your data. The same human signs in with Google on Tuesday and through their employer's SAML on Wednesday. Same email, two identity assertions, and your just in time provisioning creates two user records. Their orders and tickets are now split, and neither view is complete. SSO fails as a data modelling problem far more often than it fails as a cryptography problem.

Every tenant brings a different identity provider, and one brings none

"Add SSO" is not one integration. In a real partner portal you will end up supporting Okta, Microsoft Entra ID, Google Workspace, at least one company still running on premise ADFS, and a long tail of partners who have no identity provider at all and need email and password with a forced multi factor step. That last group is usually the majority by headcount and always the group the quote forgot.

The specifics that eat weeks: SAML 2.0 and OIDC are different enough that supporting both is two code paths, not one flag. Entra ID happily sends an unsolicited IdP initiated POST from the app launcher, and several libraries reject unsolicited responses by default because InResponseTo is absent, so login works from your site and fails from the customer's dashboard. Signing certificates rotate, and if you pasted the certificate into a config field instead of polling the federation metadata URL, you get a 3am page from every user in that tenant at once. Clock drift on a customer's own ADFS box breaks NotBefore and NotOnOrAfter validation intermittently, which is the worst kind of bug to reproduce.

The decision that matters most costs nothing to get right and a fortune to get wrong: never key the user record on email. Use the immutable identifier, a persistent NameID in SAML or the oid or sub claim in OIDC, and treat email as a mutable attribute. A competent build also uses a vetted library rather than parsing XML by hand, because XML signature wrapping is a real class of authentication bypass and libraries like ruby-saml have shipped bypass CVEs more than once. If your developer is writing their own assertion parser, stop the project.

Deprovisioning is the part that gets audited

Login is the demo. Offboarding is the contract. The standard is SCIM 2.0, and your customer's IT team will ask for it by name once they are past about 50 seats.

Building the SCIM side is more work than the SAML side, because you are now hosting an API that other people's systems write to on a schedule. Entra ID and Okta both speak SCIM and both behave differently: soft deletes arrive as a PATCH setting active to false rather than a DELETE, group membership changes arrive as PATCH operations you have to apply in order, and Entra's incremental provisioning cycle runs roughly every 40 minutes by default. So "instant offboarding" is a claim nobody can honestly make on the sync alone.

Then the harder half. Say the SCIM call lands and you flip the user inactive. If you issue one hour JWT access tokens, that user still has up to an hour of live access, plus whatever a refresh token buys them. A build that has been through a security review handles this deliberately: short access tokens with a revocation check on sensitive routes, OIDC Back-Channel Logout so the IdP can kill sessions it knows about, and an explicit session table you can nuke. Do not plan on SAML Single Logout saving you. It is specified, it is implemented inconsistently, and in practice it works for about half the tenants you try it on.

SSO tells you who, not what they are allowed to see

Authentication is maybe 40 percent of this capability. The rest is authorisation inside a multi-tenant boundary, and that is where portals leak.

The classic bug is not exotic. A partner opens /api/orders/8842, the query filters on the order ID but not the tenant ID, and they read another partner's order. Every portal build should assume this bug exists until proven otherwise. The defences that hold: scope every query at the data layer rather than the controller, use Postgres row level security or an equivalent so a missing filter fails closed, and write authorisation tests where the assertion is a 404 for a valid ID belonging to another tenant.

Then there is delegated administration, which buyers ask for casually and which is a whole feature: partner admins invite and remove their own users, assign roles, and cannot escalate themselves or see anything outside their org. Mapping directory groups to your roles sounds easy until you hit the overflow. Entra ID stops emitting group claims in the token past roughly 150 groups in SAML and around 200 in a JWT, and instead sends a link telling you to go ask Microsoft Graph. Your role mapping then silently breaks for exactly one customer: the biggest one, because they have the most groups. A competent build resolves groups through Graph or the Okta API from the start, or restricts the claim to groups assigned to the application.

The infrastructure nobody quotes: cookies, domains, and test tenants

The SAML POST binding sends the assertion from the identity provider's domain to your assertion consumer service. That is a cross site POST. A relay state or session cookie marked SameSite=Lax is not sent on it, so login fails in one browser and works in another and the ticket says "SSO is broken in Chrome". The fix is a cookie explicitly marked SameSite=None; Secure, and knowing that in advance is worth about three days.

Per tenant custom domains, the portal.customer.com CNAME that enterprise buyers love, bring their own bill: automated certificate issuance over ACME with DNS validation, renewal monitoring, and a weekly issuance cap per registered domain that a bulk onboarding of 80 partner subdomains can hit in an afternoon. Check your certificate authority's current rate limits against your onboarding plan before launch week, not during it.

And you cannot test any of this against mocks alone. You need real tenants. Okta gives you a free developer org. Entra ID lets you configure a SAML application on the free tier, but Conditional Access, which your customer's security team will insist on, needs a P1 licence. Google Workspace has no free tier, so testing that path means paying for a subscription. Budget for a small lab of real identity providers, and budget for the calendar cost: a single configuration change inside a large enterprise's Okta instance routinely takes two to three weeks of tickets. Their IT queue is on your critical path and you cannot compress it.

What this costs and how long it takes

Across 2,000+ projects delivered at Digital Heroes, the bands for this capability land consistently:

Adding SSO and user lifecycle to a product you already have: $15,000 to $60,000. The low end is one identity provider, OIDC, no SCIM, roles hardcoded in your database. The high end is SAML plus OIDC, two or three certified providers, SCIM inbound, delegated admin and an audit log.

Portal plus SSO as part of a first release: $50,000 to $130,000 in 10 to 16 weeks. This is the common shape: a real portal with documents, orders or tickets, tenant scoping done properly from day one, and enterprise login.

A full partner platform: $150,000 to $350,000 over 6 to 12 months. Many tenants, delegated administration, per tenant branding and domains, SCIM in both directions, granular permissions, audit trails suitable for SOC 2 evidence.

What actually pushes this capability's number up, in order: the count of distinct identity providers you must certify against, since each new one is roughly 1 to 2 weeks of integration plus a customer IT cycle. Then SCIM, which is typically a third of the identity budget on its own. Then delegated administration. Then migrating existing password users onto SSO without locking anyone out, which needs a dual mode window where both paths work and a linking flow for duplicate accounts. Screen count barely moves the needle. Identity provider count moves everything.

When you should not build this

If you have fewer than roughly ten enterprise customers asking for SSO, no on premise deployment requirement, and no contractual reason identity data must stay in your infrastructure, do not build the identity layer. Buy it. WorkOS, Auth0 Organizations, Stytch, Clerk and Frontegg all sell this exact shape and price it per SSO connection per month. You get SAML, OIDC, SCIM, the provider quirks, the CVE patching and the certificate rotation as somebody else's job.

Price it against your real number rather than a list price you half remember. Get a quote for your projected connection count over three years, then cost the build at a fully loaded engineer rate against the identity work only, not the portal. Then add the line every build omits: certificate rotation, CVE tracking on your SAML library, and a fresh provider certification every time sales closes a logo running ADFS. The crossover is usually not where founders think it is.

Build it yourself when one of these is true: you deploy on premise or air gapped and cannot call a hosted identity service; a contract or a regulator says user records may not leave your infrastructure; you have hundreds of tenants and per connection pricing has clearly crossed your fully loaded engineering cost; or identity is the product, not a door into it. Everyone else should buy the identity plumbing and spend the saved eight weeks on the portal features their customers actually asked for.

How to brief and vet whoever builds it

Brief with facts, not adjectives. List every identity provider by name and version, including the ADFS box. State how many tenants, whether partner admins manage their own users, whether SCIM is contractual, whether custom domains are promised, and how many existing password users must be migrated. That one page changes quotes by a factor of three, which tells you how much guessing was happening before.

Then ask these, and listen for specifics rather than confidence:

What happens when a user's email changes at the identity provider? Anyone who has shipped this says immediately that email is never the key, and names the persistent NameID or the oid claim. Anyone who has not will say something about an update script.

How do you revoke access within 60 seconds of a SCIM deprovision? A good answer covers short access tokens, a server side session store, and back channel logout. A bad answer is "the token expires".

What breaks when a customer has 400 groups in Entra ID? If they have not met the group overflow claim, they have not run this at enterprise size.

How do you defend against XML signature wrapping, and which SAML library are you using? The right answer names a maintained library, admits that library has had CVEs, and describes how they track them.

Why does SSO login fail in Chrome but work in your local dev? If SameSite cookie behaviour on the assertion POST is not the first thing they say, they have not debugged a real integration.

And the one that ends the conversation fastest: show me a recording of you configuring a SAML app in an Okta tenant and logging into something you built. Fifteen minutes of screen share separates people who have read the spec from people who have shipped against it. Ask for it before you sign anything.