Introduction to Identity Proxy at DOTNET Zuid

After visiting DOTNET Zuid meetups several times past year, I decided that it was time to propose a talk myself. Over the past years, I’ve been building an Identity Proxy. This is a topic I am passionate about, and I know most developers struggle with authentication and authorization in their applications. So I thought it would be a great idea to share my knowledge and experience with the community.

Dotnet Zuid

DOTNET Zuid is a community-driven meetup for .NET developers in the south of the Netherlands, though they also have a frequent attendee from Ermelo! They organize meetups 8 tot 10 times a year, featuring talks on various topics. The meetups are free for attendees, but you have to pay a small fee if you signed up and don’t show up. This ensures that people are committed to attending the event, and the food is not wasted.

Be sure to check out their website and consider attending one of their meetups if you’re in the area! If you want to speak at this local event, you can submit your proposal via their sessionize page.

Introducing Identity Proxy

January 20th 2026 was the day I was scheduled to give my talk on Identity Proxy. I’ve giving this talk at several other events, but I try to change it a bit every time. This time I introduced some polls using EngageTime to make it more interactive. The introduction to Identity Proxy was well received, during the talk there were some good questions from the audience, and after the talk several people approached me to discuss it further.

Status code when accessing resources for an other user

I was very surprised by the poll results about the status code that should be returned when a user tries to access resources for another user.

• 60% of the audience thought it should be a 403 Forbidden
• 21% of the audience thought it should be a 401 Unauthorized
• 14% of the audience thought it should be a 404 Not Found

This fueled a great discussion about this topic. My opinion is that a 404 Not Found is the best option. That way you don’t give away any information about the existence of the resource. In some branches this is a security requirement. I’m very curious to hear your opinion on this topic.

Map fallback for unauthenticated users

When building a minimal API that does not require authentication for all endpoints, you might consider removing the default 404 response for unauthenticated users. Giving them zero information about which endpoints might exist or not. You can achieve this by mapping a fallback endpoint that returns a 401 Unauthorized for unauthenticated users, and a 404 Not Found for authenticated users. For readability this is split into multiple lines, but you can of course write it in a single line as well.

// Unauthenticated users get a 401, authenticated users get a 404 for unknown endpoints
app.MapFallback((HttpContext context) =>
{
    if(context.User.Identity?.IsAuthenticated ?? false)
    {
        return Results.Problem(statusCode: 404, title: "Endpoint Not Found", detail: "The requested endpoint does not exist.");
    }
    else
    {
        return Results.Unauthorized();
    }
}).ExcludeFromDescription();

Test all endpoints for authentication

When building an API, it is smart to include this basic test to ensure that all endpoints require authentication, unless explicitly excluded. If you want to test this in your own project, check out this TUnit test or the xUnit test.

This simple test will do the following:

1. Load all endpoints from the OpenAPI specification
2. (optional not included) Exclude endpoints that are explicitly excluded from the tests
3. Execute the Endpoint_should_return_statuscode_401_without_valid_token test for each endpoint
4. The test will send a request without an Authorization header and expect a 401 Unauthorized response

It might need some adjustments to work in your own project if you use numbers for IDs in the path, but it should be a good starting point.

Question “Can you use Identity Proxy in a pipeline?”

The most notable question from the audience was if you can use the Identity Proxy in a CI/CD pipeline, since it is using docker. The answer is yes, in both GitHub Actions and Azure DevOps the agent has access to the docker daemon. I’m not exactly sure where this is documented, but I believe they use docker-in-docker to achieve this. As in the agent has the docker cli installed and the docker socket from the host machine is mounted into the agent container.

In the sample api recipers (a by-design unsafe API for managing recipes) is a GitHub Actions workflow that runs the xunit and the tunit tests both using the Identity Proxy.

Closing thoughts

Speaking at dotnet Zuid was a great experience, if you’re ever in the neighbourhood, be sure to check out one of their meetups. If you want to speak here, be sure to submit your proposal via sessionize. And lastly make sure you don’t contribute to Owasp top 10 A01:2025 - Broken Access Control, I hope we can get rid of “Broken Access Control” once and for all. Security and access tokens should not be scary for developers.

Happy coding and testing!