Should a SaaS startup build its own authentication?

No. Password storage, session handling, reset flows, and second factors are solved problems with no competitive upside and severe downside. The failures are subtle, they are invisible until exploited, and none of them make your product better. Buy the login, and spend the effort on what happens after it.

The practice of pricing single sign on only into the most expensive tier, so an enterprise buyer who requires SAML or OIDC login must move to it. It applies to you twice: your identity vendor charges you more for the feature, and you will likely charge your own enterprise customers more for it in turn.

What is SCIM and when will I need it?

SCIM is the protocol that lets a customer's directory create, update, and deactivate accounts in your product automatically. You will need it the first time a buyer asks how an employee loses access on their last day, which happens later than the single sign on request and is harder to satisfy after the fact.

How hard is it to change identity providers later?

Harder than any other vendor swap, because sessions, user identifiers, and password hashes are all involved and your users notice immediately. Some providers will export password hashes and some will not, and that single detail decides whether a migration is invisible to users or requires everyone to reset.

Authentication: What to Buy and What to Never Build

Nobody has ever chosen your product because the login was good, and the cost of getting it subtly wrong is unbounded. Buy authentication.

The decision that matters is which provider you can still live with in three years. It turns on two things founders rarely check before signing: what single sign on costs, and whether you can leave.

Buy or build: what you are actually deciding

Authentication is one of the few parts of a product where the correct amount of originality is zero. Every user expects it to work exactly as it does everywhere else, nobody has ever chosen a product because of it, and the cost of getting it subtly wrong is unbounded.

So the interesting decision is not build versus buy. That one is settled. The decision is which provider you can still live with in three years, and the deciding factor is almost never the thing founders evaluate on, which is how quickly they can get a login page working this afternoon.

Password storage, sessions, reset and MFA: never build these

Not because it is hard to write, but because it is hard to know you got right. Each of these fails silently and stays failed until someone exploits it. NIST’s digital identity guidelines and the OWASP authentication cheat sheet between them describe what getting each one right involves, which is the fastest way to see why you should not.

Password storage. The difference between an adequate and a dangerous implementation is invisible in testing and decisive after a database leak.
Session management. Token generation, expiry, invalidation on password change, and revocation across devices. Most homegrown implementations get the first and miss the rest, which means a stolen session stays valid long after the account was secured.
Password reset. A perennial target, because it is by design a way to obtain access without knowing the password. Token lifetime, single use, and what the flow reveals about whether an account exists are all easy to get wrong.
Second factors. Time based codes look simple and are surrounded by details that are not: replay windows, recovery codes, and what happens when a user loses their device.

None of these are interesting problems. All of them are ones you would be solving in parallel with a company whose entire business is solving them.

What buying authentication actually costs

Buying is correct and it is not free. The costs are real, and they arrive later than the decision.

Cost	When it arrives
Per user pricing	When you grow, and it compounds
The SSO tax	At your first enterprise deal
Provisioning gaps	When a buyer asks about leavers
Migration difficulty	The day you want to leave
Availability coupling	Immediately, and invisibly

The last one deserves naming because founders rarely price it. Your identity provider is now on the critical path for every session in your product. Their outage is your outage, and it is the kind of outage where nobody can log in to see your status page.

The SSO tax is the one that shapes your vendor choice. Single sign on is frequently priced into the top tier, so the feature your first enterprise buyer treats as non negotiable is the feature that moves you up a pricing bracket. Find out what that bracket costs before you choose a provider, not during the deal that depends on it.

And the migration question is worth asking on day one, when it is a two minute conversation with a salesperson rather than a project. Ask whether they will export password hashes on exit. A provider who will is a provider you can leave without every one of your users noticing. A provider who will not has made the decision permanent, and they know it.

Where buying authentication goes wrong

Buying the login and building everything after it. The provider tells you who the user is. Deciding what that user may do, usually through role-based access control, is still your problem, and it is the part that governs your actual exposure.
Treating identity as a launch task. It is chosen once at the point of minimum information and lived with for the life of the product.
Meeting the SSO request with a bespoke integration. The first one takes a fortnight and works. The fourth one, each slightly different, is a permanent tax on the team.
Ignoring deprovisioning. Single sign on controls how people get in. It does nothing about the employee who left three months ago, unless provisioning is wired up too. Buyers ask about the second one later, and expect it to already work.
Letting support staff impersonate users without a record. A convenient feature, added quickly, that becomes the widest access path in the product and the hardest to explain in an audit.

Questions to ask an identity provider

Ask these of a provider before signing, and of your own team afterwards.

Will you export our password hashes if we leave, in a format we can import elsewhere?
Which pricing tier includes SAML and OIDC single sign on, and what does that tier cost at our expected size in two years?
Do you support SCIM provisioning, and on which tier?
When a session is revoked, how long can the old token still be used?
What happens to our login page during your outage, and what is your published availability history rather than your target?
In our own product, who can act as another user, and where is that recorded?

The last one is not about the vendor at all, and it is the question most likely to surface something uncomfortable this week.

Start here. Email your identity provider and ask, in writing, whether they will export your password hashes if you leave. The answer decides whether your next migration is invisible to users or forces every one of them to reset.

Nobody has ever bought your product because the login was good. Several companies have lost theirs because it was not.