How to choose

Build, buy or open source? Five questions

1. Is login your product? If you're an identity company, build. Otherwise buy a hosted service or run a maintained open-source server, and keep your engineers on organizations, roles and the setup flow customers see.
2. Who signs in? Consumers push you toward a per-user meter and passkeys; employees of large companies toward SSO, SCIM and audit logs, priced per connection.
3. How many connections? Per-connection pricing is cheap for 10 large customers and expensive for 200 small ones, so run both meters at the size you expect in two years.
4. Where must data live? Strict residency rules point to self-hosting (Keycloak, or a vendor's private deployment), which needs a team that patches, upgrades and answers the page at 3 a.m.
5. How complex are permissions? A few roles per organization fit in your own code. Sharing, folders, nested teams and per-record exceptions point to a relationship engine such as OpenFGA or SpiceDB, and several products sharing one model point to a central policy service.

My defaults: hosted login with organizations from day one, on a free tier while it lasts. Passkeys plus emailed codes, MFA required for admins, and no SMS unless a market demands it. Roles stored per organization from the very beginning, because retrofitting multi-tenancy is painful. SSO and SCIM through a vendor until its fees approach the cost of a person, with every SCIM deactivation also revoking sessions, tokens, keys and grants. Access tokens of 5-15 minutes and single-use refresh tokens. One deny-by-default permission function called from every endpoint and tested across two customers, and a relationship engine before I'd write my own graph. An audit log from the earliest enterprise customer, and SAML left to a maintained library or vendor.