We've taken a slightly different approach to this at WorkOS. (I'm the founder.) We decided to handle authentication but explicitly _not_ user management or aut

We've taken a slightly different approach to this at WorkOS. (I'm the founder.) We decided to handle authentication but explicitly _not_ user management or authorization. This means our API is essentially just an OAuth2 wrapper around enterprise identity systems like Okta, Microsoft ADFS, generic SAML, OpenID Connect, etc. We don't require developers to migrate users into WorkOS, handle access policy, or "own" the user object. The primary user database always stays in the developer's app and WorkOS just serves as an authentication gateway. This turns out to be much more flexible, faster to integrate, and ultimately what developers actually want when adding advanced authentication strategies to their app (like enterprise SSO). So I guess what I'm saying is this article title is a bit of a misnomer. It's actually about outsourcing your user management and identity infrastructure to FusionAuth, which is a much larger decision with architectural effects. And unfortunately that results in strong vendor lock-in to a platform like FusionAuth (or Auth0). (For anyone curious, you can see more about the WorkOS approach here: https://workos.com/docs https://workos.com/docs)