Insufficient Logging in Aspnet with Bearer Tokens

Insufficient logging in ASP.NET APIs that rely on bearer token authentication creates a blind spot for security and incident response. When tokens are accepted but events are not recorded, an attacker can probe the API, and operators have no reliable audit trail to reconstruct what happened.

In ASP.NET, bearer tokens are typically validated by the authentication middleware. If logging does not capture token usage details—such as whether a token was accepted, rejected, expired, or used to access specific endpoints—anomalies like token reuse, abuse, or leakage are harder to detect. For example, an attacker using a stolen token might make repeated, low-volume requests that evade threshold-based alerts if those requests are not logged with sufficient context.

Specific gaps include missing logs for authentication successes and failures, lack of correlation identifiers tying a request to a token and a user, and absence of token metadata (e.g., scopes, issuer, audience). Without these, it is difficult to identify patterns such as privilege escalation attempts, token sharing across accounts, or requests from unexpected IP addresses or geolocations. In regulated environments, insufficient logging can also complicate forensic investigations and compliance reporting.

ASP.NET logging integrations (such as ILogger) can be configured to emit structured logs, but they must explicitly include security-sensitive events from the authentication layer. If the default logging configuration excludes token validation events, developers may assume authentication is silent when in fact it should be observable. This misalignment between authentication processing and telemetry increases the risk that compromised tokens remain undetected.

Additionally, logs that contain tokens or sensitive user data introduce new risks. If token values are accidentally written to logs, the logging system itself becomes a target. Therefore, sufficient logging must strike a balance: capturing enough detail to detect abuse without persisting raw tokens or personally identifiable information.

Remediation focuses on ensuring that authentication events are explicitly logged with useful, non-sensitive context, and that logs provide enough information to trace token usage without compromising security.

First, configure ASP.NET Core to log authentication successes and failures. Use the built-in logging categories for Microsoft.AspNetCore.Authentication. You can set the verbosity via configuration or code. For example, in Program.cs, increase logging for authentication events:

// Program.cs
builder.Logging.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Warning);
builder.Logging.AddFilter("Microsoft.AspNetCore.Authentication", Microsoft.Extensions.Logging.LogLevel.Information);
builder.Logging.AddFilter("Microsoft.AspNetCore.Authorization", Microsoft.Extensions.Logging.LogLevel.Information);

Second, log key details in a structured way within your authentication events. Avoid logging raw tokens. Instead, log token metadata and request context:

// Example logging within a custom event handler or middleware
var logger = loggerFactory.CreateLogger("TokenAudit");
logger.LogInformation("Token validated. Issuer: {Issuer}, Audience: {Audience}, Scopes: {Scopes}, ClientId: {ClientId}, Endpoint: {Endpoint}, Status: {Status}"
    , issuer, audience, string.Join(",", scopes), clientId, requestPath, status);

Third, ensure logs include a request identifier that can be correlated across services. In ASP.NET, you can use Activity.Current?.Id or inject IHttpContextAccessor to capture and log correlation IDs:

// Example middleware to enrich logs with correlation id
app.Use((context, next) =>
{
    var correlationId = Activity.Current?.Id ?? context.TraceIdentifier;
    context.Items["CorrelationId"] = correlationId;
    // Optionally add to logger via IHttpContextAccessor
    return next();
});

Fourth, log authorization decisions when using policies and roles. This helps detect privilege escalation or unauthorized scope usage:

// Example logging in an authorization handler or filter
if (!context.Succeeded)
{
    logger.LogWarning("Authorization failed. User: {User}, Policy: {Policy}, Resource: {Resource}"
        , user?.Identity?.Name, context.HandlerName, context.Resource);
}

Fifth, protect log data at rest and in transit. Ensure logs do not contain raw access or refresh tokens. Use structured logging sinks that support redaction if necessary, and apply retention policies that align with compliance requirements.

Finally, integrate these logs with monitoring and alerting pipelines to detect anomalies such as repeated token validation failures, tokens used from multiple distinct IPs within a short window, or usage of high-privilege scopes not normally observed for a given client.