DuendeSoftware/products

Authorization code is not properly redacted when logging raw values

Closed this issue · 2 comments

Hello,

We are using Duende.IdentityServer 6.2.3 and .NET 6.0.14.

Describe the bug

During custom token request validation error flows (ICustomTokenRequestValidator.ValidateAsync), we are seeing authorization codes being printed in plaintext and not properly redacted in the raw value dumped in our logs (ApplicationInsights).

To Reproduce

The bug can be seen when logs are written for multiple validation error scenarios, e.g. attempting to validate a CustomTokenRequestValidationContext using an implementation of ICustomTokenRequestValidator when LaunchContext.Properties is null or when a user (retrieved using ValidatedRequest.Subject) is disabled or not present in the user store.

When validation errors occur, we expect the raw dump to have properly redacted all sensitive information before logging to ApplicationInsights.

Log output/exception with stacktrace

Untitled

# Expected logs when "code" is properly redacted during an invalid user flow.

Custom token request validator{ error: "invalid_user" }, details: TokenRequestValidationLog 
{ ClientId: "myClientId", ClientName: "myClientName", GrantType: "authorization_code", 
Scopes: null, AuthorizationCode: "****6C-1", RefreshToken: "********", UserName: null, 
AuthenticationContextReferenceClasses: null, Tenant: null, IdP: null, 
Raw: [("grant_type": "authorization_code"), ("code": "***REDACTED***"), 
("redirect_uri": "myRedirectUri"), ("code_verifier": "myCodeVerifier"), 
("client_id": "myClientId"), ("client_secret": "***REDACTED***")] }

Additional context

In the example screenshots, we can see that the AuthorizationCode property is properly censored, but the code property in the raw is not. These logs seem to be produced by IdentityServer/TokenRequestValidator.cs line 274 and IdentityServer/TokenRequestValidationLog.cs.

Hi, thanks for raising this issue. The cause of this issue seems to be that the default value for the TokenRequestSensitiveValuesFilter option doesn't include the code. We're going to consider changing that default, but as a workaround, you can set that option to include code. The current default is to filter client_secret, password, client_assertion, refresh_token, and device_code, so I would set the option to include all of those values, and also code.

Okay, we're going to change the default in the 6.3 release for consistency between the raw and parsed value. But to put your mind at ease about logs you already have, I just want to point out that codes are one time use only, so by the time they are logged they should not be useful any more.