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.

[symposion]

@jgrandja This is a bit more radical than I suspect you were thinking. It's not complete but I wanted to get some feedback on the approach. Just modifying OAuth2ClientAuthenticationFilter isn't totally straightforward. The problem is that in the case of missing authentication, we end up throwing an AccessDenied exception from AuthorizationManager, which doesn't really join up with any of the other parts of the Spring Auth Server implementation at the moment.

Furthermore, I've noticed that there are several places with somewhat duplicated code handling authentication errors. With this in mind, I've taken some inspiration from the implementation in the OAuth2 resource server, which centralises the handling of both authentication failure and missing authentication by sharing an AuthenticationEntryPoint between the ExceptionTranslationFilter and the BearerTokenAuthenticationFilter to achieve consistency in the way it formats 401 responses across the board. I think this is cleaner than just catching AccessDenied in the OAuth2ClientAuthenticationFilter and completely bypassing all the normal spring security mechanisms for handling this flow.

In the case of Spring Auth Server, there's a certain amount of stuff that doesn't really fit in an AuthenticationEntryPoint + there was already an existing class that seemed suitable for re-use : OAuth2ErrorAuthenticationFailureHandler . I've made this a bit more generic and expanded the usage to basically everywhere that handles authentication failures, including a new AuthenticationEntryPoint that defers to it.

I think this approach fits better with the way this is handled in other places by Spring security - such as the standard web security, or the resource server implementation; and also results in a bit less code duplication.

If you don't completely hate this, then I need to think about whether this handler should actually be a shared object so that the realm can be configured centrally somehow.

[jgrandja]

@symposion There are too many touch points in the latest updates and I'm very confident that we can isolate the required changes to OAuth2ClientAuthenticationFilter only.

Just modifying OAuth2ClientAuthenticationFilter isn't totally straightforward. The problem is that in the case of missing authentication, we end up throwing an AccessDenied exception from AuthorizationManager, which doesn't really join up with any of the other parts of the Spring Auth Server implementation at the moment.

For the "no client authentication included" use case, we can add a check here:

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

Line 135 in f1d5427

if (authenticationRequest instanceof AbstractAuthenticationToken) {

if (authenticationRequest == null) {
	// TODO No client authentication included
	// Reuse and enhance the default authenticationFailureHandler to return 401 WWW-Authenticate: Basic

}

Makes sense?

[symposion]

@symposion There are too many touch points in the latest updates and I'm very confident that we can isolate the required changes to OAuth2ClientAuthenticationFilter only.

Just modifying OAuth2ClientAuthenticationFilter isn't totally straightforward. The problem is that in the case of missing authentication, we end up throwing an AccessDenied exception from AuthorizationManager, which doesn't really join up with any of the other parts of the Spring Auth Server implementation at the moment.

For the "no client authentication included" use case, we can add a check here:

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

Line 135 in f1d5427

if (authenticationRequest instanceof AbstractAuthenticationToken) {

if (authenticationRequest == null) {
	// TODO No client authentication included
	// Reuse and enhance the default authenticationFailureHandler to return 401 WWW-Authenticate: Basic

}

Makes sense?

Yes, I can do that. The big downside I see with doing that - and why I didn't propose that - is that we're effectively bypassing all of the normal authorization behaviour of Spring Security. Spring Authorization Server currently uses these mechanisms to define the authentication requirements for its various endpoints. If I make the change you're proposing, anyone who is expecting to be able to customise this in the normal way using authorizeHttpRequests etc is going to be surprised, as is anyone who expects to be able to configure an AccessDeniedHandler or an AuthenticationEntryPoint that interacts with the token endpoint.

At the very least, if we're going to take this approach I think we're going to need some way to disable it so people can choose to have the filter chain proceed as normal down to the AuthorizationFilter if the authentication is null - which would be the normal flow in Spring Security.

[jgrandja]

anyone who is expecting to be able to customise this in the normal way using authorizeHttpRequests etc is going to be surprised

The token endpoint is not intended to be compatible with authorizeHttpRequests() as the only actor is the OAuth2 Client and the only requirement for a (confidential or public) client is authentication. Furthermore, authorization decisioning for OAuth2 clients is not specified in any of the specs so I don't believe users would configure something like authorize.requestMatchers("/oauth2/token").hasRole("CLIENT_ROLE1").

[symposion]

anyone who is expecting to be able to customise this in the normal way using authorizeHttpRequests etc is going to be surprised

The token endpoint is not intended to be compatible with authorizeHttpRequests() as the only actor is the OAuth2 Client and the only requirement for a (confidential or public) client is authentication. Furthermore, authorization decisioning for OAuth2 clients is not specified in any of the specs so I don't believe users would configure something like authorize.requestMatchers("/oauth2/token").hasRole("CLIENT_ROLE1").

Understood. I will re-implement the simpler way.