Broken Authentication in Aspnet with Bearer Tokens

Broken Authentication in ASP.NET when Bearer Tokens are used typically arises from insecure token handling and weak validation practices. Bearer Tokens rely on the assumption that whoever presents the token is the rightful owner; if tokens are not properly protected, forged, or leaked, attackers can impersonate users without needing credentials.

Common weak spots include accepting unsigned or weakly signed tokens, failing to validate the issuer (iss) and audience (aud) claims, not enforcing token expiration, and storing tokens insecurely on the client or server. In ASP.NET, developers sometimes use AddAuthentication(JwtBearerDefaults.AuthenticationScheme) but omit critical validation settings, which allows malformed or tampered tokens to be accepted.

Another vector is token leakage in logs, URLs, or browser storage. For example, embedding tokens in query strings can expose them in server logs or browser history. Additionally, missing or misconfigured CORS policies can enable cross-origin token theft via malicious scripts. An attacker who obtains a Bearer Token can then make authenticated API calls until the token expires or is revoked.

Consider an API built with ASP.NET Core that exposes an endpoint like /api/orders and relies solely on the presence of a Bearer Token without additional checks. If the token validation does not enforce nonce or replay protections, an attacker could capture a token via a man-in-the-middle attack on an unencrypted channel and reuse it. This becomes especially dangerous when combined with insufficient transport layer protections or when tokens have long lifetimes.

OWASP API Security Top 10 lists Broken Object Level Authorization (BOLA) and Broken Authentication as frequently overlapping issues. Insecure Bearer Token usage can enable BOLA when access control checks are missing or bypassed, allowing one user to manipulate or view another user’s resources by simply changing an identifier in the request. This is a realistic threat pattern seen in the wild and tracked under common CVE entries related to authorization bypass.

To detect such risks, middleBrick runs checks aligned with the OWASP API Top 10 and maps findings to frameworks like PCI-DSS and SOC2. The scanner tests unauthenticated attack surfaces, so it can identify missing authentication requirements on endpoints that should be protected, as well as weak token validation logic.

Remediation centers on strict token validation, secure transmission, and defense-in-depth practices. In ASP.NET Core, you should configure JWT Bearer options to enforce strong validation rules and minimize the attack surface.

First, always validate token signatures, issuer, audience, and lifetime. The following code demonstrates a secure setup in Program.cs:

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://your-identity-provider.com",
            ValidateAudience = true,
            ValidAudience = "https://your-api-audience",
            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(2),
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"])
            )
        };
        options.RequireHttpsMetadata = true;
    });

builder.Services.AddAuthorization();

var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();

Second, protect tokens in transit by enforcing HTTPS and avoiding query strings. Store tokens securely on the client, for example using HttpOnly cookies when feasible, or secure browser storage with strict SameSite and Secure flags if using JavaScript clients. Never log tokens or include them in URLs.

Third, keep token lifetimes short and implement refresh token rotation with strict validation. If your architecture requires long-lived sessions, use sliding expiration and revoke tokens on logout or suspicious activity. The following example shows a policy that enforces short access token lifetimes:

builder.Services.Configure<JwtBearerOptions>(JwtBearerDefaults.AuthenticationScheme, options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateLifetime = true,
        // short access token lifetime in minutes
        // actual expiration is enforced by the token handler
    };
});

Finally, apply per-endpoint authorization checks and avoid relying on a single Bearer Token for critical operations. Combine role-based and resource-based checks to reduce the impact of a leaked token. middleBrick’s scans can verify that authentication is required on sensitive endpoints and that token validation is correctly configured.