DEV Community: Fmaes

Rate limiting login and registration in a .NET 10 Minimal API (per IP, no extra packages)

Fmaes — Sat, 17 Oct 2026 16:35:29 +0000

The code lives in a public repo and is tested in CI.

This is part 3 of the series about my free, MIT-licensed .NET 10 Minimal API starter. In part 1 I covered the base template, and in part 2 I added per-user ownership of resources.

Today: protecting /register and /login from brute-force attempts with the rate limiter that ships with ASP.NET Core. No NuGet package needed.

What I wanted

Limit only the auth endpoints, not the whole API.
Limit per client IP, so one noisy client doesn't lock everyone out.
Return a proper 429 Too Many Requests with a Retry-After header and a ProblemDetails body.
Make the limits configurable from appsettings.json.
Keep the existing integration tests unaffected.

1. Options bound from configuration

public sealed class AuthRateLimitOptions
{
    public const string Section = "RateLimiting:Auth";
    public int PermitLimit { get; init; } = 5;     // requests allowed...
    public int WindowSeconds { get; init; } = 60;  // ...per window
}

This is a plain class that holds the two numbers. The defaults are 5 requests per 60 seconds, and anyone can override them in configuration.

2. The policy

public static class RateLimitingExtensions
{
    public const string AuthPolicy = "auth";

    public static IServiceCollection AddAuthRateLimiting(
        this IServiceCollection services, IConfiguration configuration)
    {
        var settings = configuration.GetSection(AuthRateLimitOptions.Section).Get<AuthRateLimitOptions>()
                       ?? new AuthRateLimitOptions();

        services.AddRateLimiter(options =>
        {
            options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

            options.AddPolicy(AuthPolicy, httpContext =>
                RateLimitPartition.GetFixedWindowLimiter(
                    httpContext.Connection.RemoteIpAddress?.ToString() ?? "unknown",
                    _ => new FixedWindowRateLimiterOptions
                    {
                        PermitLimit = settings.PermitLimit,
                        Window = TimeSpan.FromSeconds(settings.WindowSeconds),
                        QueueLimit = 0
                    }));

            options.OnRejected = async (context, ct) =>
            {
                if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter))
                {
                    context.HttpContext.Response.Headers.RetryAfter =
                        ((int)Math.Ceiling(retryAfter.TotalSeconds)).ToString(CultureInfo.InvariantCulture);
                }

                await context.HttpContext.Response.WriteAsJsonAsync(new ProblemDetails
                {
                    Status = StatusCodes.Status429TooManyRequests,
                    Title = "Too many requests. Try again later."
                }, ct);
            };
        });

        return services;
    }
}

What each piece does:

AddPolicy registers a named policy. Endpoints opt in by name, so everything else stays unlimited.
RateLimitPartition.GetFixedWindowLimiter creates one independent counter for each partition key. Using the IP as the key gives you one bucket per client.
QueueLimit = 0 means that excess requests get a 429 right away instead of waiting.
OnRejected sets the Retry-After header and writes a ProblemDetails response, so the error looks like every other error in the API.

3. Wiring it up

builder.Services.AddAuthRateLimiting(builder.Configuration);

// ...
app.UseHttpsRedirection();
app.UseRateLimiter();      // before authentication
app.UseAuthentication();
app.UseAuthorization();

Then I opt the two endpoints in:

group.MapPost("/register", Register)
    .AddEndpointFilter<ValidationFilter<RegisterRequest>>()
    .RequireRateLimiting(RateLimitingExtensions.AuthPolicy);

group.MapPost("/login", Login)
    .AddEndpointFilter<ValidationFilter<LoginRequest>>()
    .RequireRateLimiting(RateLimitingExtensions.AuthPolicy);

UseRateLimiter() goes before UseAuthentication() so that abusive requests are rejected before any password hashing happens.

4. Testing it without breaking the other tests

Every integration test calls /register and /login, so a limit of 5 per minute would make the whole suite flaky. My ApiFactory (the shared WebApplicationFactory) raises the limit:

builder.UseSetting("RateLimiting:Auth:PermitLimit", "1000");

A dedicated factory then lowers it to 3 for the one test that checks the limiter itself:

builder.UseSetting("RateLimiting:Auth:PermitLimit", "3");

[Fact]
public async Task Login_is_rate_limited_after_too_many_attempts()
{
    var body = new { email = "nobody@test.com", password = "Wrong1234!" };

    for (var i = 0; i < 3; i++)
    {
        var allowed = await _client.PostAsJsonAsync("/api/auth/login", body);
        Assert.Equal(HttpStatusCode.Unauthorized, allowed.StatusCode);
    }

    var blocked = await _client.PostAsJsonAsync("/api/auth/login", body);

    Assert.Equal(HttpStatusCode.TooManyRequests, blocked.StatusCode);
    Assert.NotNull(blocked.Headers.RetryAfter);
}

The tests run in CI like everything else, and I also checked the 429 by hand with the .http file.

Limitations

This setup is intentionally simple, and you should know where it stops:

Behind a reverse proxy (nginx, a cloud load balancer), RemoteIpAddress is the proxy's IP unless you configure UseForwardedHeaders. Otherwise all your users share one bucket.
The counters live in memory, per instance. If you scale to several instances, each one counts separately. For that you'd need a distributed approach (e.g. Redis).
It limits by IP, not by account. Someone spreading attempts across many IPs is not stopped. A per-account lockout is on my list.

Try it

Next up: a /health endpoint that checks the database, and refresh tokens. If you have feedback or want something covered, open a Discussion.

Per-user ownership in a .NET Minimal API (and how the user reaches your endpoint)

Fmaes — Fri, 16 Oct 2026 17:14:26 +0000

Update: A reader pointed out that the sub / NameIdentifier split comes from MapInboundClaims on JwtBearerOptions, which defaults to true. Setting it to false keeps the raw JWT claim names, so GetRequiredUserId no longer needs the fallback. The starter now does exactly that (see the change). Thanks, @mehdimohseni82 ! The explanation below still describes the default behavior.

In the first post I shared a .NET 10 starter template and listed what it doesn't do yet. The biggest item on that list was this: any authenticated user could update or delete any product. This post is about fixing that, and about a question I had along the way: how does my endpoint know who the user is?

Repo: https://github.com/Fmaes2/dotnet-minimal-api-starter

The rule

Any authenticated user can read products.
Only the owner can update or delete a product.
Anyone else gets 403 Forbidden.

1. Store the owner

The product gets an OwnerId, and the database enforces it with a foreign key to the Identity users table:

public class Product
{
    // ...
    public string OwnerId { get; set; } = "";
}

modelBuilder.Entity<Product>(e =>
{
    // ...
    e.HasOne<IdentityUser>()
        .WithMany()
        .HasForeignKey(p => p.OwnerId)
        .IsRequired()
        .OnDelete(DeleteBehavior.Cascade);
});

The id is a string because IdentityUser uses a string key (a GUID). IsRequired() means a product can't be saved without an owner, so forgetting to set it fails loudly instead of silently.

2. How does the endpoint know who the user is?

Here is what actually happens on a request with an Authorization: Bearer <token> header:

app.UseAuthentication() runs before any endpoint. It calls the JWT bearer handler.
The handler reads the header, validates the token (signature, issuer, audience, expiry) and builds a ClaimsPrincipal from the token's claims.
That principal is stored in HttpContext.User. No header, or an invalid token, leaves the user anonymous.
app.UseAuthorization() checks RequireAuthorization() and rejects anonymous users with 401 before your handler runs.
When a handler declares a ClaimsPrincipal user parameter, Minimal APIs fills it with HttpContext.User. It doesn't come from the body or the query string.

So your endpoint never reads the header. It just receives what the middleware prepared, which also means the same handler would work unchanged if you switched to cookie authentication.

To read the id from the principal I added a small extension method:

public static string GetRequiredUserId(this ClaimsPrincipal user) =>
    user.FindFirst(ClaimTypes.NameIdentifier)?.Value
    ?? user.FindFirst(JwtRegisteredClaimNames.Sub)?.Value
    ?? throw new InvalidOperationException("The authenticated user has no id claim.");

Depending on the handler configuration, the id can show up as sub or as NameIdentifier, so it checks both. If neither exists it throws: endpoints require authentication and the tokens always carry sub, so that would be a programming error, not a client error.

3. Check the owner in the endpoints

On create, the owner comes from the token, never from the request body. The request type doesn't even have an owner field, so nobody can create a product in someone else's name.

On update and delete:

var product = await db.Products.FindAsync(id);
if (product is null) return TypedResults.NotFound();
if (product.OwnerId != user.GetRequiredUserId()) return TypedResults.Forbid();

Why 403 and not 404? Because any authenticated user can already read every product, so the fact that it exists is not a secret. If reads were private, I'd return 404 for other people's products so the API doesn't reveal which ids exist.

The handler's return type is a Results<Ok<...>, NotFound, ForbidHttpResult> union, so OpenAPI documents all three responses and the compiler complains if a case is not handled.

4. Testing with two users

The tests that matter use two users at once:

[Fact]
public async Task Another_user_cannot_update_a_product_they_do_not_own()
{
    var owner = CreateClientFor(await RegisterAndLoginAsync());
    var intruder = CreateClientFor(await RegisterAndLoginAsync());
    var id = await CreateProductAsync(owner);

    var response = await intruder.PutAsJsonAsync($"/api/products/{id}",
        new ProductRequest("Hacked", null, 1m));

    Assert.Equal(HttpStatusCode.Forbidden, response.StatusCode);

    var current = await owner.GetFromJsonAsync<ProductResponse>($"/api/products/{id}");
    Assert.Equal("Original", current!.Name);
}

The last two lines are the important part. Checking the status code alone would pass even if the API rejected the request after saving the change. Reading the product back proves it was not modified. There's an equivalent test for delete.

Bonus: `GET /api/auth/me`

While I was at it, I added an endpoint that returns the id and email of the authenticated user. It reads everything from the token claims and doesn't touch the database. It's also a handy way to see exactly what is in your token.

Gotchas

The migration adds a required column, so a database that already contains products can't take it as is. In development I recreated the database; in a real project you'd backfill an owner first.
Listing still returns everyone's products. Making each user see only their own is a different decision, and I haven't made it yet.
There are no roles yet, so no admin can edit other people's products.

What's next

Rate limiting on the login endpoint is next on my list. If you'd rather see something else first (refresh tokens, roles, a health check that actually checks the database), tell me in the comments or in the Discussions.

A .NET 10 Minimal API starter, so you can skip the boilerplate

Fmaes — Mon, 12 Oct 2026 15:59:05 +0000

Starting a new .NET API means spending hours on the same setup before you write the first useful line: authentication, error handling, validation, logging, Docker, tests and CI. I got tired of repeating it on every project, so I packaged it into a template and put it on GitHub for anyone who wants to skip that part.

Repo: https://github.com/Fmaes2/dotnet-minimal-api-starter

Who is this for?

People learning ASP.NET Core who want a small, working API to read, run and modify instead of starting from an empty project.
Developers who want to spin up a small side project quickly without rebuilding the same foundation again.

It's a starting point and a learning reference, not a production-ready base. More on that below.

What's inside

Minimal APIs organized by feature with MapGroup
ASP.NET Core Identity with JWT authentication
EF Core with PostgreSQL, migrations and paginated endpoints
FluentValidation through a reusable endpoint filter
Global error handling with ProblemDetails
Serilog logging to console and file
Unit and integration tests (xUnit, Moq, in-memory SQLite)
Dockerfile and docker-compose with a database healthcheck
GitHub Actions CI

A few decisions worth mentioning

Minimal APIs, but not a giant Program.cs. Each feature lives in its own file with an extension method, and a route group takes care of the shared pieces:

var group = app.MapGroup("/api/products")
    .WithTags("Products")
    .RequireAuthorization();

group.MapPost("/", Create).AddEndpointFilter<ValidationFilter<ProductRequest>>();

The group applies the route prefix, the OpenAPI tag and the authorization requirement to every endpoint inside it, and the filter validates the request body before the handler runs.

Integration tests that don't need Docker. They run against in-memory SQLite, so dotnet test works on a fresh machine. The trade-off is that SQLite and PostgreSQL differ in small details, and the README says so.

Try it

docker compose up --build

The README covers the local development flow too, and how to add your own entity by copying the products feature. The repo is MIT licensed and marked as a template, so you can use the Use this template button.

What it's not (yet)

I'd rather tell you now than have you find out later:

Update: product ownership is now implemented. Read how it works in the second post.

Anyone can register, and login attempts aren't limited. There's no lockout or rate limiting.

Tokens last 60 minutes with no refresh or revocation.

/health always answers "ok" without checking the database.

Endpoints talk to the DbContext directly. That's fine for a simple CRUD, but you'll want more structure as the business logic grows.

What would you add?

I'm deciding what to build next. If you've set up a .NET API recently, what took you the most time? Refresh tokens, roles, ownership checks, multi-tenancy, something else? Tell me in the comments or open a Discussion.

DEV Community: Fmaes

Rate limiting login and registration in a .NET 10 Minimal API (per IP, no extra packages)

What I wanted

1. Options bound from configuration

2. The policy

3. Wiring it up

4. Testing it without breaking the other tests

Limitations

Try it

Per-user ownership in a .NET Minimal API (and how the user reaches your endpoint)

The rule

1. Store the owner

2. How does the endpoint know who the user is?

3. Check the owner in the endpoints

4. Testing with two users

Bonus: GET /api/auth/me

Gotchas

What's next

A .NET 10 Minimal API starter, so you can skip the boilerplate

Who is this for?

What's inside

A few decisions worth mentioning

Try it

What it's not (yet)

What would you add?

Bonus: `GET /api/auth/me`