We have many requests for App registrations to configure “Single Page Apps” or traditional “Web Apps” for authentication between applications using Entra. Has anyone looked at Workload Identities as an alternative?
Alternatively, does anyone have recommendations to minimize the number of “Single Page Apps”? I get requests to create 10 to 20 of these per week.
Howdy, how big is your org that you getting that amount of requests per week??
Also, are they actual applications?
That seems like quite a lot.
I’m more interested in why your org is creating those apps.
First, a quick clarification on terminology since it comes up a lot: “Workload Identity” is an umbrella term for any non-human identity in Entra ID. Under that umbrella you have a few distinct things, App Registrations/Service Principals, Managed Identities, and Workload Identity Federation. Managed Identity is a specific type of workload identity, not a synonym for it. That distinction matters when we’re talking about what controls and policies apply.
For app-to-app authentication (no user involved), moving toward the right workload identity pattern is absolutely the right direction. App registrations configured as Single Page Apps or Web Apps are designed for user-facing authentication flows (OAuth authorization code, OIDC), so using them for service-to-service communication is working against the grain. A service principal with tightly scoped API permissions is cleaner, more auditable, and purpose-built for that scenario.
Here’s where the different workload identity types shine and where we get better security controls:
Managed Identities: This may be what you are looking to implement or your requests. You can learn more about Managed Identities HERE. For anything running inside Azure (VMs, App Service, Functions, AKS), Managed Identities should be the default. No app registration required, no credentials to manage or rotate, and they integrate directly with Azure RBAC. The identity lifecycle is tied to the resource itself. This is the lowest-friction, highest-security option when it’s available.
Service Principals (App Registrations without the SPA/Web App config): For workloads running outside Azure, or where you need cross-tenant access, a service principal is the right tool. This is where credential hygiene matters most; HOWEVER….. you should be standardizing on certificates over client secrets, or better yet Workload Identity Federation for workloads in GitHub Actions, Azure DevOps, or Kubernetes.
Conditional Access for Workload Identities: Consider this, Entra ID supports Conditional Access policies specifically targeting service principals. We can restrict authentication to known IP ranges or trusted locations, block sign-ins outside expected network boundaries, and enforce compliant credential types.
On minimizing Single Page App registrations: a big driver of the volume is likely teams treating each app or environment (dev/staging/prod) as a separate registration, or using SPAs for flows that don’t involve a user at all. Some practical ways to reduce this:
One of the most impactful things you could do is to have a comprehensive discovery intake form that teams must complete before a registration is created. The form should capture key routing questions like whether a user is actually signing in, where the workload is hosted, what APIs or resources it needs to access, and whether the workload has an existing identity provider.
Happy to put together a decision framework or lightweight intake policy if that would be useful.
We have about 15,000 people. Much of our business is fintech and we have large application development teams building applications in AWS and using Entra for authentication, mostly with OICD, but also SAML. It seems every “function” becomes an independent application. I agree if feels like too much, but I don’t know of alternatives to provide authentication with MFA to these micro-applications as well as normal applications.
Hey DBennett,
Thinking out loud with you here…
The more I mull over your situation, the more it feels like you’re hitting an architectural consequence rather than a pure Entra “hygiene” issue. If every “function” is intentionally treated as its own app (for isolation, team ownership, simple per‑app permissions, etc.), then a separate app registration per function is kind of the natural outcome: each one needs its own client ID, redirect URIs, and permission surface.
I’m also wondering what’s driving that granularity. Is it mainly security boundaries, separate deployment pipelines, or just “this is how teams learned to do OIDC with Entra”? Because if the requirement is “these things should really behave like distinct applications from an identity perspective,” Entra is just faithfully reflecting that model with lots of app registrations.
One possible alternative I keep circling back to is grouping functionality behind a smaller number of Entra apps. For example: a single “shell” or suite app registration that fronts multiple micro‑apps/modules. That would cut down app registrations, but then you trade off:
You can’t easily target each micro‑app separately with Conditional Access anymore, because Entra only sees the outer app.
All the fine‑grained “who can use which function” logic has to move into the application: roles/claims in the token, internal authorization checks, maybe a custom permission model instead of Entra‑level separation.
Reviews/consent/blast radius happen at the level of that shared app, so changes for one module can affect others.
So I keep ending up at: if the business really wants “hard” separation between these micro‑apps, then a lot of app registrations is a logical side effect. If you want fewer registrations, something higher up in the architecture probably has to change, and you’d push more of the per‑app control from Entra into app‑level authorization and configuration.
Now I might have side‑tracked a bit with this thought pattern, so if you feel like I missed an important angle or constraint in your environment, do share.