Proposed fix for missing WWW-Authenticate header

[symposion]

Current implementation does not include the WWW-Authenticate header when returning a 401 for missing/invalid credentials when attempting to access the token endpoints. This PR would change to use the standard BasicAuthenticationEntryPoint in order to populate this header correctly.

I will add testing if the fix approach is considered acceptable

[jgrandja]

Please revert the changes in this class and instead add the fix here:

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/web/OAuth2ClientAuthenticationFilter.java

Line 207 in a8c4f94

// TODO

[symposion]

Please revert the changes in this class and instead add the fix here:

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/web/OAuth2ClientAuthenticationFilter.java

Line 207 in a8c4f94

// TODO

Ah, I see now how this is handled there. I will change this, but as a side note, I'm a bit confused about what the point of adding the HttpStatusEntryPoint in the OAuth2AuthorizationServerConfigurer is in that case. The Spring Boot autoconfiguration seems to override this anyway by registering a LoginUrlEntryPoint; but if the autoconfiguration isn't used and this HttpStatusEntryPoint is registered, it seems to have some odd consequences:

1. Per the implementation of org.springframework.security.config.annotation.web.configurers.ExceptionHandlingConfigurer#createDefaultEntryPoint when there's only one mapping, this becomes the default entrypoint for all URLs, not just the ones it was actually registered for - which doesn't seem like it would be the intention here.
2. But in fact AFAICT this is irrelevant because I think all of the auth server filters catch AuthenticationExceptions and handle them explicitly rather than allowing them to propagate out to the ExceptionTranslationFilter

So on the one hand I'm puzzled about whether this bit of configuration ever really does anything useful; and on the other I'm concerned that if it does have a purpose it might not really be correct anyway because:

1. It will, by default, apply to more than just the URLs it's configured for (effectively any URL handled by this filter chain) and
2. It's still not clear to me that it's ever really acceptable to return a 401 without a www-authenticate header according to the HTTP spec: https://datatracker.ietf.org/doc/html/rfc7235#section-3.1

[jgrandja]

what the point of adding the HttpStatusEntryPoint in the OAuth2AuthorizationServerConfigurer is in that case

By default, client authentication is required for the Token endpoint, Token Introspection endpoint, Token Revocation endpoint and Device Authorization endpoint. Therefore, this is added as a sensible default in case it passes through the OAuth2ClientAuthenticationFilter, which won't happen with the default configuration, but may happen if client authentication is customized and misconfigured. Consider this sensible default as a defense-in-depth measure.

[symposion]

Right, understood. As currently being discussed on the original issue comments, I'm unconvinced that this is valid without a WWW-Authenticate header, and thus I'd argue that this change should probably stay, in addition to updating the OAuth2ClientAuthenticationFilter

[jgrandja]

@symposion

The Spring team has recently migrated to the Developer Certificate of Origin (DCO) for our contribution process. See Submitting Pull Requests for additional details on the new process. Please format the commits in this PR as the DCO check did not pass.