I've used AWS Cognito and Supabase before, and I'm also very familiar with ASP.NET Core Identity. After enjoying Azure Functions and Cosmos DB on another project, I decided to build my next SaaS entirely on Azure and use Microsoft Entra External ID for authentication.
So far, the experience has been frustrating. Terraform supports only a limited portion of the setup, the interface mixes concepts from classic Entra and the newer external identity features, and the documentation can be difficult to follow. AI-assisted guidance has also sent me down conflicting paths, including advice about changing user flows to support personal Microsoft accounts.
My biggest concern is security. Because external identity settings are presented alongside internal Entra configuration, I'm worried about accidentally granting customer accounts access to Azure resources or creating an unintended security boundary. The lack of Terraform support for important items such as user flows makes this harder to validate and reproduce.
I realize some of the difficulty comes from my lack of Entra experience, but as a small SaaS developer, I want authentication to be reliable without spending weeks becoming an identity specialist. Is Entra External ID realistically aimed at small SaaS projects, or would something like Cognito, Supabase, Auth0, or Keycloak be a better fit?
5 Answers
For a small product, Auth0 is generally more automated and easier to get started with, although it has its own pricing and customization trade-offs. Keycloak is another option if you want more control, but it requires a stronger understanding of identity standards and more operational responsibility. The best choice depends on whether you value simplicity, control, or staying tightly integrated with Azure.
Several teams have found Entra External ID less complete than competing customer-identity platforms. It may work well if Azure integration is the top priority, but for a small SaaS where authentication should be mostly handled for you, switching back to a simpler provider could be a reasonable decision. Do a trial implementation and pay close attention to automation, documentation, tenant isolation, and how easy it is to reproduce the configuration.
Be cautious about relying on AI-generated setup instructions. Identity products have lots of version-specific terminology, and AI tools often combine older documentation with newer features. If you use one, connect it to the official Microsoft documentation source, such as the Microsoft Docs MCP server, and verify every security-sensitive step manually.
It’s not necessarily a bad choice, but it has a steep learning curve and still requires too many manual steps. The product and terminology are evolving, and some of the documentation feels incomplete or inconsistent. Compared with more focused identity providers, it may demand more platform-specific knowledge than a small SaaS team wants to invest.
Make sure the customer directory is separate from the tenant that hosts your Azure resources. That separation helps reduce the risk of external users being treated like internal identities, although it doesn’t solve the underlying usability and documentation problems.
That separation is useful, but it doesn’t completely address my concern. If the guides and AI recommendations disagree, it’s still difficult to know whether I’m configuring the product safely or missing an important security boundary.
I wasn’t aware of the Microsoft Docs MCP server, so I’ll try grounding the AI guidance in the official documentation. That may help with accuracy, although the product’s overall complexity is still a concern.