EasyAuth Dev Proxy, now with Aspire

A striking mural on a city building in downtown New York City, showcasing urban art and architecture. Picture by Matthis Volquardsen on Pexels

EasyAuth Dev Proxy, now with Aspire

Posted 17 Aug 2026

Back in February 2024 I published a solution for working with Easy Auth in local development. I built it to scratch my own itch, because Azure Container Apps has no support for working with EasyAuth in local development. If you've ever worked with Azure Static Web Apps CLI you know how easy EasyAuth can really be. Unfortunately there is still no dev tooling for Container Apps, there's an open issue on the Container Apps repo asking Microsoft for exactly this, unanswered two years later.

So, it's time for a new release. With Aspire now well established as a local dev orchestration tool, I wanted to add support for that. A containerized version of the tool had been in the works for a while and that is now also available. That takes the EasyAuth Dev Proxy from a work-around to a proper development tool.

An Aspire resource, not a second terminal

The initial release required a separate process started with dotnet run --urls=... --backend=... in its own terminal, kept in sync by hand with whatever port your backend happened to be on that day. If you're on Aspire now, that's gone. The Alanta.Aspire.Hosting.EasyAuthProxy NuGet package adds the proxy as a fluent extension on your AppHost:

var builder = DistributedApplication.CreateBuilder(args);

var catalogService = builder.AddProject<Projects.CatalogService>("catalog");

// Add EasyAuth proxy with fluent configuration
var easyAuthProxy = builder.AddEasyAuthProxy("easyauth")
    .WithBackend(catalogService)
    .WithHostPort(8888);

builder.Build().Run();

This runs the proxy straight from the NuGet package, so it does require .NET to be available on your dev box.

Aspire uses service discovery, which enables name-based resolution using the WithBackend extension. It takes the backend's IResourceBuilder directly, so Aspire can wire up the services; no URL to type or keep in sync. The proxy shows up as just another resource in the Aspire dashboard, with its own logs, health state and start/stop lifecycle tied to everything else in the graph. aspire run brings the whole thing up, Easy Auth included, in one command.

Run from a container

If you don't have .NET available, the new release has you covered as well. The latest version is published as ghcr.io/alanta/easyauthdevproxy on GitHub Container Registry. That's a real expansion of who can use this, not just a packaging detail: it means running the proxy no longer requires the .NET SDK at all. Anyone with Docker or Podman can bring up the proxy in front of their app, whatever that app is written in:

docker run --network=host -d --rm ghcr.io/alanta/easyauthdevproxy:latest -e backend=http://localhost:5191 -p 8080:8888

You can orchestrate with Docker Compose if you prefer. Note though that no TLS certificate is bundled in the image, so this setup is HTTP-only.

The Aspire extensions also enable the containerized version to run using the AddEasyAuthProxyContainer() extension:

var easyAuthProxy = builder.AddEasyAuthProxyContainer("easyauth")
    .WithBackend(catalogService)
    .WithHostPort(8888);

Same ghcr.io/alanta/easyauthdevproxy image, wired into Aspire's resource graph like any other container resource.

It doesn't care what your backend is written in

None of this requires Aspire, or even .NET. The proxy only ever talks HTTP to your backend and injects headers. If your backend is a Python or Node service checking X-MS-CLIENT-PRINCIPAL the same way a Container Apps deployment would, the standalone container works exactly the same in front of it. Aspire just makes the wiring nicer if you're already using it.

TLDR;

Put together, this is a bigger jump than "faster setup" — it's more situations where the proxy is actually an option:

Test role-gated code paths without a real identity provider. A simple UI allows you to set the login and pick roles. No Entra test accounts to provision per persona, no waiting on whoever owns the tenant.
Smooth orchestration on Aspire and .NET. AddEasyAuthProxy() runs as a bundled subprocess, effortless for .NET developers who don't want a container runtime as a dependency for a dev-only tool.
Run in any dev environment. The container image means anyone with Docker or Podman can run the proxy in front of their app. A frontend or Python developer on a polyglot team can get the same fake-login experience without installing a .NET toolchain just for this.

Try it

If you're already on Aspire, add a reference to Alanta.Aspire.Hosting.EasyAuthProxy and call AddEasyAuthProxy() in your AppHost. If you're not, the original dotnet run --urls=... --backend=... workflow from the 2024 post still works unchanged, and the standalone container works in front of any backend, any language.

Full docs and the source are on GitHub.

Developer Notes