Authentication is the part of a SaaS product customers never praise and where every mistake is expensive. The choice between an integrated solution, a self-hosted toolkit and a managed service is therefore rarely about features, but about where user data should live and how tightly you want to be bound.
The deciding point: where user data lives
With authentication integrated into the database, accounts live in the same database as the rest of the data. That allows foreign keys to the user table, access rules based directly on it and export without detours. With an external managed service, accounts live with the provider; the product holds a copy or a reference, and every query linking user data with business data needs synchronisation. That synchronisation is where such set-ups break in practice: an account is deleted at the provider, the local copy remains, and somewhere a reference points nowhere. It is solvable, but it is permanent work.
The case for integrated authentication
If you already use a platform that includes authentication, you get access rules based directly on the signed-in person without passing a token through several layers. For multi-tenant applications with row-level security this is a considerable advantage: identity is available where the rule is evaluated. The limit lies in requirements beyond the standard, such as sign-in through the customer’s identity provider, fine-grained organisation structures or certifications procurement demands.
The case for a managed service
Managed providers take on work that is underestimated: ready-made sign-in and registration screens, organisation and invitation management, multi-factor authentication and detection of suspicious logins. The decisive point comes later: once business customers require integration with their own identity provider, that is configuration with a managed provider and a project when self-built. Against a managed service speak usage-based costs that grow with success and dependence on another vendor, including from a data protection perspective, because accounts are personal data and the provider joins your processing chain.
Self-hosted toolkits
A self-hosted toolkit is a middle path: full control over data, no usage-based costs, but responsibility for updates, fixes and operation. That is defensible if someone in the team genuinely understands the fundamentals. Not defensible is implementing the core components yourself: password storage, session management, password reset. These are solved problems, and every home-grown version creates a new attack surface.
The requirement that changes everything
Once a customer demands sign-in through their own identity provider, the calculation changes. In the German-speaking B2B market that is standard from a certain customer size and regularly appears in the security questionnaire before the contract is discussed. Ask before choosing: is this a customer segment we are targeting? If yes, the answer to that question will cost more than any other property.
What you build yourself regardless
Whatever you choose, three things remain your job. Authorisation: being signed in does not mean being permitted; checking whether this person may access this resource belongs in your application. Mapping accounts to tenants and roles: no provider knows your permission model. And complete deletion of an account across all systems, which with an external provider means two deletion processes that must both be reliable. The underlying concepts are explained in our glossary entries on SSO with SAML and OIDC, row-level security and permission concepts.