Missing Authentication in Aspnet with Bearer Tokens

Missing authentication in an ASP.NET API that uses bearer tokens occurs when an endpoint does not enforce token validation, allowing unauthenticated requests to reach business logic. This can happen when the authentication middleware is not configured, is applied selectively, or is bypassed by permissive route patterns. Even if bearer token handling is implemented, missing or misconfigured authorization policies can leave routes unprotected.

In ASP.NET, the framework relies on the authentication and authorization services in the pipeline. If AddAuthentication and AddAuthorization are not correctly set up for JWT bearer schemes, or if policy-based authorization is omitted, the system may not reject requests that lack a valid token. Developers might assume that requiring authentication is sufficient, while failing to ensure every controller or action enforces it consistently.

A concrete misconfiguration is omitting the authentication scheme when requiring authentication. For example, calling [Authorize] without specifying the policy or scheme can lead to ambiguous behavior if multiple authentication handlers are registered. Similarly, using [AllowAnonymous] on controllers or actions intended to be public can inadvertently expose sensitive endpoints when applied too broadly.

Consider an endpoint that should require a bearer token but lacks explicit authentication requirements:

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace InsecureApi.Controllers
{
    [ApiController]
    [Route("api/v1/users")]
    public class UsersController : ControllerBase
    {
        [HttpGet("{id}")]
        // Missing [Authorize] or misconfigured policy
        public IActionResult GetUser(Guid id)
        {
            // Business logic that should be protected
            var user = new { Id = id, Name = "Alice" };
            return Ok(user);
        }
    }
}

In this example, any unauthenticated request to /api/v1/users/{id} will succeed, exposing user data without validation. This illustrates a BOLA/IDOR scenario where an attacker can enumerate or manipulate identifiers because no token is verified.

middleBrick detects such missing authentication controls as part of its Authentication and BOLA/IDOR checks. By submitting an unauthenticated request to the endpoint, the scanner observes whether the response reveals sensitive data or behavior that should be restricted. Findings include the endpoint path, the missing enforcement of bearer token validation, and the potential for unauthorized access to data or functionality.

Another subtle issue arises when authentication is configured but authorization policies are not aligned with the intended security model. For instance, a policy might require a claim that is not present in the validated token, causing legitimate requests to be rejected while still allowing unauthenticated traffic in edge cases. middleBrick cross-references the OpenAPI specification, if provided, with runtime behavior to identify discrepancies between declared security requirements and actual enforcement.

To summarize, missing authentication in ASP.NET with bearer tokens typically stems from absent or inconsistent use of [Authorize], incomplete middleware setup, or incorrect policy binding. These gaps enable unauthenticated access to endpoints, which can be leveraged for IDOR, data exposure, or privilege escalation. Effective security requires validating tokens on every relevant route and ensuring that authorization policies are explicit and applied consistently.

Remediation focuses on ensuring that every endpoint requiring protection enforces bearer token validation and appropriate authorization. This involves correct setup of authentication services, explicit authorization attributes, and well-defined policies that map to your security requirements.

First, configure authentication in Program.cs using the JWT Bearer scheme. Specify the expected issuer, audience, and validate the token signature correctly:

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.Authority = "https://your-identity-provider";
        options.Audience = "api1";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = "https://your-identity-provider",
            ValidAudience = "api1",
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes("YourVeryStrongAndSecretKeyAtLeast32BytesLong!!"))
        };
    });

builder.Services.AddAuthorization();

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

Next, apply the [Authorize] attribute at the controller or action level. Prefer policy-based authorization when different roles or claims are required:

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

namespace SecureApi.Controllers
{
    [ApiController]
    [Route("api/v1/users")]
    [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
    public class UsersController : ControllerBase
    {
        [HttpGet("{id}")]
        [Authorize(Policy = "RequireAdminRole")]
        public IActionResult GetUser(Guid id)
        {
            var user = new { Id = id, Name = "Alice" };
            return Ok(user);
        }
    }
}

Define policies in Program.cs to enforce role or claim requirements precisely:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdminRole", policy =>
        policy.RequireRole("Admin"));
    options.AddPolicy("RequireScope", policy =>
        policy.RequireClaim("scope", "api.read"));
});

Ensure that the incoming token contains the expected claims and roles. If your API relies on specific claims for business logic (such as user ID or tenant ID), validate those explicitly in the authorization handler or within the action, rather than relying on the mere presence of a token.

When integrating with identity providers, verify token audiences and issuers strictly to prevent confusion attacks. Avoid accepting tokens intended for other APIs or audiences. The remediation examples above enforce bearer token validation and role-based access, reducing the risk of unauthenticated access and BOLA/IDOR.

middleBrick’s scans validate these configurations by checking whether authenticated and authorized requests are required and whether anonymous access is possible. The tool surfaces specific remediation guidance tied to each finding, helping you align implementation with security best practices.