This week we spent a few days scoping single sign-on. Here’s what we found, what we picked, and why.
Small CRMs don’t usually publish their internal engineering research. We think they should. You’re trusting a piece of software to hold your customer relationships — you deserve to see how we’re thinking about the bigger architectural decisions, not just read the marketing copy after we’ve already shipped.
A very short explanation before we dive in: single sign-on, usually shortened to SSO, means “log into HARi using the same credentials your company already uses for everything else” — typically Microsoft 365 or Google Workspace. If you’re running a 10-person business on HARi today, you almost certainly don’t need this. But some companies — particularly regulated ones — cannot legally use software that doesn’t support SSO. This post is about how we’re making HARi work for those buyers without breaking anything for the rest of you.
Who SSO is for, and who it isn’t
Let’s be direct about this, because it matters to how you read the rest of the post.
If you run a 5-to-20 person business in Hong Kong — a trading firm, a clinic, a creative agency, a property practice — you do not need SSO. Email and password with a strong password policy and two-factor authentication (which HARi already supports) is the right answer for you.
So who does need it? Law firms above a certain size. Private banks and their custody arms. Hong Kong financial-services-regulated entities operating under HKMA or SFC oversight. Listed companies with an IT security department. Regional offices of large international groups. These buyers have procurement processes that include an IT security checklist, and somewhere on that checklist is a line that says something like: “Does the vendor support SAML 2.0 SSO and SCIM user provisioning?” If the answer is no, the deal doesn’t move forward. Sales can’t override it. It’s a hard gate.
HARi today doesn’t support SSO, which means HARi has been structurally excluded from an entire segment of the Hong Kong market. We wanted to understand whether fixing that was a reasonable engineering investment, and if so, how to do it without compromising what makes HARi good for everyone else.
What “SSO” actually means when an enterprise buyer asks for it
When an enterprise buyer says “we need SSO,” they usually mean three things bundled together. It’s worth naming them, because the word “SSO” on its own is vague.
-
SAML 2.0 is the old enterprise federation standard, XML-based, dating from around 2005. It’s still the baseline requirement in 2026 for any buyer running Microsoft Entra ID, Okta, Ping, or OneLogin. It’s not pretty — signed XML assertions, X.509 certificate rotation, IdP-initiated versus service-provider-initiated flows — but every corporate identity team knows how to configure it.
-
OIDC (OpenID Connect) is the modern equivalent, built as an identity layer on top of OAuth 2.0. It’s JSON-based instead of XML, much simpler, and it’s what Google Workspace and Azure AD’s modern endpoints prefer. If a buyer is on Google Workspace, OIDC is the faster path for everyone involved.
-
SCIM 2.0 is the one people forget to ask about but it’s the compliance-critical piece. It’s the protocol that lets your HR system automatically deprovision a user in HARi when they leave the company. When someone is terminated in Workday, the change propagates to Azure AD, which tells HARi to deactivate that account within minutes, no human in the loop. Security auditors look for this specifically — the alternative (someone manually remembering to revoke access) is how ex-employees keep customer data on their laptops for months after they leave.
Buyers who need SSO usually need all three. “Login with Google” alone doesn’t satisfy the checklist.
We looked at four providers
We did not want to build this from scratch. The SAML specification is a 200-page document, every identity provider interprets it slightly differently, and there is no mature PHP library for SCIM. A reasonable estimate for building SAML + OIDC + SCIM from scratch to the point where it passes both Okta and Azure AD compliance tests is 6 to 9 weeks of engineering time, plus permanent maintenance as certificates rotate and new IdP quirks surface. That’s not a good use of engineering time — we’d rather spend those weeks on things our users will actually notice.
So we looked at four providers, all of whom sell SSO-as-a-service to B2B SaaS companies.
WorkOS has an official PHP SDK that’s actively maintained, and their entire product is built around the “one SaaS serves many tenant-customers, each with their own identity provider” model. That’s exactly our architecture. Pricing is per-connection-per-month: US$125 at small volume, sliding down to about US$50 at higher volume. SAML, OIDC, and SCIM all ship behind one integration. The caveat we’re still working through is APAC data residency — WorkOS defaults to US servers, EU available on request, but their APAC posture isn’t publicly disclosed. We’re verifying with their sales team before selling to HK-regulated buyers.
Clerk has great developer experience but is heavily frontend-focused (React, Next.js) and publishes no PHP SDK. For HARi’s PHP backend, that’s a disqualifier — calling a REST API directly gives up most of the reason you’d buy a provider.
Auth0 by Okta is the big name in the space and it’s mature, but the pricing model double-meters: you pay for monthly active users and for each additional SSO connection. At HARi’s scale — tenants with hundreds of users — those numbers compound quickly, and you end up paying more for identical capability than you would with WorkOS. Auth0 is also a larger, broader platform; B2B is a subset of what they do.
Stytch has a generous free tier (10,000 monthly active users, 5 SSO or SCIM connections) that would cover HARi’s first five Enterprise customers at zero cost. But like Clerk, no PHP SDK, only REST. Same disqualifier.
The criteria that mattered most: PHP SDK quality, fit with a multi-tenant architecture where each customer has their own identity provider, pricing that stays reasonable as we grow, and some kind of plausible story for buyers who care about where their authentication data transits.
We picked WorkOS. Mature PHP SDK, multi-tenant-native, economics that work at our scale, honest caveat about APAC residency that we’re actively working to resolve. The cost works out to roughly US$250 per Enterprise customer per month for SSO plus SCIM combined. That’s absorbable inside an Enterprise contract — not a margin killer.
What we’re not doing
A few things we want to be explicit about, because the wrong answer here would hurt the people already using HARi.
We are not building this from scratch. There are over 100 identity provider variants in active use globally, each with their own edge cases around certificate rotation, metadata refresh, assertion formatting. This is exactly the kind of problem where a provider earns its fee.
We are not changing the HK$1,990 flat plan. SSO will be an Enterprise-tier feature, accessed through a contact-sales process — not an optional add-on bolted onto the flat plan. The moment SSO has a line-item price on the standard plan, the slogan “one price, unlimited users” breaks. We explained our thinking on per-seat pricing in The Problem with Per-Seat Pricing; SSO pricing follows the same logic.
We are not forcing SSO on teams that don’t want it. Email, password, and two-factor authentication will remain the default for every Standard tenant, forever. If you don’t need SSO, you won’t see SSO.
Rollout plan
Our internal estimate is 6-8 weeks of engineering, broken into four phases.
Phase 1 (weeks 0-2) is the first identity provider and the OIDC foundation. We’re prioritising Microsoft Entra ID (Azure AD) and Google Workspace because between them they cover the vast majority of Hong Kong enterprise and SME-enterprise deals. Exit criterion: a test tenant admin logs into HARi via Microsoft 365.
Phase 2 (weeks 2-4) is SCIM provisioning and enforcement. Once this ships, removing a user in Azure AD automatically deactivates their HARi account within a few minutes, with full audit trail. We also add the “SSO-enforced” toggle — once on, password login is blocked for that tenant, with a break-glass option for the tenant owner.
Phase 3 (weeks 4-6) is the self-serve configuration UI inside HARi Settings. By end of Phase 3, a new tenant can configure their own IdP without us being in the loop.
Phase 4 (weeks 6-8) is the Enterprise tier going live on the pricing page — Enterprise card with a contact-sales CTA, and a sales funnel starts existing.
Total elapsed time to first paying Enterprise customer logging in via their own IdP: about six to eight weeks of focused work.
Honest caveats we’re still working through
Two things we don’t want to paper over.
First, the APAC data residency question with WorkOS. We haven’t confirmed where their infrastructure runs in Asia. For most enterprise buyers this is fine — US-based authentication with a reputable SOC 2-certified provider is an accepted industry norm — but a Hong Kong private bank asking about PDPO data localisation is a separate conversation we may need to have with legal counsel before the first bank deal. If WorkOS turns out to be US-only and that’s a blocker for regulated buyers, we’ll position Enterprise at non-regulated HK SMEs first and revisit the architecture in 2027. We’d rather tell you now than after the contract is signed.
Second, a provider dependency is a provider dependency. If WorkOS has an outage, every Enterprise tenant with SSO enforced could be locked out simultaneously. We mitigate this with a break-glass password option that’s always available for the tenant owner, and we’ll publish WorkOS incidents transparently on our status page (in the same spirit as our email infrastructure work — transparency is part of the product).
Why we’re publishing this
Most SaaS vendors run their internal research privately, ship the feature, and the blog post afterwards is marketing. We’d rather invert that: publish the reasoning while we’re making the decisions, even when some of it is unflattering (we have an unresolved APAC residency question with our preferred provider). Public roadmap beats secret roadmap for a tool you depend on.
If you have feedback — particularly if you’re a potential Enterprise buyer with a specific identity provider or a compliance requirement we haven’t thought of — email hello@haricrm.com.
Closing
If you’re running a small business on HARi today, nothing in this post changes anything for you. The HK$1,990 flat plan, unlimited users, email-and-password login — all exactly the same, today and in six months.
If your company needs SSO to procure HARi, email us at hello@haricrm.com and we’ll add you to the Enterprise early-access list. First five customers get direct access to us during their rollout, and we’ll help you plan the IdP side with your IT team.
Have a look at what else we’ve been shipping on the changelog, check the pricing page for the current Standard plan, or browse the blog for more of our thinking on how a flat-price CRM actually works under the hood.