I thought identity would be the easy, boring part.
Iâm building ProteinLens: a consumer-ish app today, with a clear path to âteams laterâ (B2B, SSO, enterprise domains). So I did what a reasonable Azure-native builder would do:
âLetâs implement Microsoft Entra External ID. Itâs basically B2C 2.0, right? Social login now, SSO later. Done.â
Reader, it was not done.
What followed was authentication chaos: portals inside portals, concepts that sound identical but arenât, and a sign-in experience that looks like I just teleported my users into someone elseâs product.
This post is for anyone who wants the simplest thing:
- email/password (or magic link)
- social auth (Google/Apple)
- subscriptions with Stripe
- a UX that feels like your app, not a detour to BigCorp Login Land
âŚand is considering Entra External ID because âfuture enterpriseâ.
The dream: B2C simplicity, future B2B power
My mental model was:
- External ID = modern CIAM
- supports social providers
- lets me evolve into SSO (SAML/OIDC) later
- and Iâm already on Azure, so itâll integrate cleanly
In my head, it was the responsible choice.
In reality, it felt like adopting an entire identity platform when I just needed a door lock.
The first UX red flag: the redirect
The moment you hit sign-in, you get a full redirect into a Microsoft-styled flow.
Even with branding, itâs still visibly ânot my productâ. The fonts, spacing, page layout, and interaction patterns donât match. It breaks trust in a consumer app.
Yes, Microsoft Entra External ID supports âbranding themesâ for the hosted pages, but the customization has real limits (and itâs tenant-level theming, not a fully native embedded experience). (Microsoft Learn)
If youâre building something where conversion matters, this is not a small detail. Authentication is part of your product, not a compliance checkbox.
The second red flag: complexity that doesnât scale down
External ID has a lot of surface area:
- external tenants vs your ânormalâ tenant
- user flows
- identity providers
- app registrations, permissions, consent screens
- multiple admin experiences and documentation paths
None of that is âwrongâ if you need it.
But if youâre shipping an MVP, itâs the identity equivalent of deploying Kubernetes to serve a static page.
I lost hours to the kind of friction that doesnât show up in architecture diagrams:
- âwhere is the setting actually applied?â
- âis this configured per app, per tenant, per user flow?â
- âwhy does the portal UI say one thing but the runtime does another?â
It wasnât hard in a fun way. It was hard in a paper-cut way.
The third red flag: the identity roadmap got weird
I also hit the uncomfortable reality: Azure AD B2C is effectively closed to new customers.
Microsoftâs own FAQ states:
- Effective May 1, 2025, Azure AD B2C is no longer available to purchase for new customers
- the experience for existing customers remains, but new tenants are restricted
- and B2C P2 is discontinued March 15, 2026 (Microsoft Learn)
So if youâre a new product today and you thought âmaybe Iâll just use classic B2C insteadâ⌠that door is basically closed.
That nudges you toward External IDâeven when External ID is not the UX you want.
Clerk isnât the answer either (for me)
I looked at Clerk.
Clerk is slick and productive, and for many teams itâs exactly right. But my issue wasnât âI want fewer lines of code.â
My issue was: I want a more seamless, product-native auth experience, and I want subscriptions + identity to feel cohesive.
Some auth tools feel like youâre renting someone elseâs UI. Some feel like identity lego bricks. I want something that feels like it belongs to ProteinLens.
So what do I actually need?
Hereâs the brutally honest scope:
- Create user
- Log in user
- Social login (Google + Apple)
- Reset password / email verification
- Link Stripe customer + subscription state to that user
- Keep the UX consistent
Everything else is optional until itâs not.
And when âitâs notâ (B2B/SSO later), I want to add that without rebuilding the world.
What Iâm doing instead
Iâm optimizing for shipping + UX + control, not âenterprise future-proofingâ on day one.
A pragmatic approach that fits this stage:
- Use a modern auth layer that lets me own the UI (or fully match it)
- Keep identity data in my database (or at least keep a clean mapping)
- Treat Stripe as billing truth, and attach it to my user model
- Design the system so SSO is an add-on, not the foundation
Concretely, that usually means one of these patterns:
Option A: App-owned auth (fast, flexible, UX-perfect)
- Auth in-app with a library like Auth.js / NextAuth-style flows (or equivalent for your stack)
- Social providers via OAuth
- Sessions/JWT controlled by your backend
- Stripe customer/subscription references stored in your DB
This is the âI want controlâ path.
Option B: A hosted auth provider that supports embedded / fully themed experiences
Not all âhosted authâ is equal. Some tools allow deep theming or embedded components that truly match your UI; others will always feel like a redirect.
If redirect UX bothers you today, pick a provider that doesnât force it.
Option C: Defer enterprise SSO until you have enterprise users
This is the heresy take, but itâs often correct.
You donât need SAML because you might have enterprise customers later. You need SAML because someone is ready to pay you for it.
The real takeaway: identity can be a product decision, not an infrastructure decision
Entra External ID is powerful. I can see it being the right choice for:
- regulated orgs
- existing Microsoft-heavy enterprises
- multi-app suites that want centralized tenant-wide governance
- scenarios where the Microsoft-hosted journey is acceptable (or preferred)
But for a consumer SaaS MVP where trust + flow + conversion matter?
The combination of:
- redirect experience that doesnât feel native
- high cognitive load
- a confusing B2C transition era (Microsoft Learn)
âŚmade it the wrong tool for my current stage.
So Iâm going back to basics:
Own the experience. Keep auth simple. Integrate Stripe cleanly. Add SSO when itâs paid for.
