Proposed fix for missing WWW-Authenticate header #1877
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
| @@ -344,7 +355,9 @@ public void init(HttpSecurity httpSecurity) throws Exception { | |||
| ExceptionHandlingConfigurer<HttpSecurity> exceptionHandling = httpSecurity | |||
| .getConfigurer(ExceptionHandlingConfigurer.class); | |||
| if (exceptionHandling != null) { | |||
| exceptionHandling.defaultAuthenticationEntryPointFor(new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED), | |||
| var entryPoint = new BasicAuthenticationEntryPoint(); | |||
There was a problem hiding this comment.
Please revert the changes in this class and instead add the fix here:
There was a problem hiding this comment.
Please revert the changes in this class and instead add the fix here:
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:
- 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.
- 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:
- It will, by default, apply to more than just the URLs it's configured for (effectively any URL handled by this filter chain) and
- 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
There was a problem hiding this comment.
what the point of adding the
HttpStatusEntryPointin theOAuth2AuthorizationServerConfigureris 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.
There was a problem hiding this comment.
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
added
type: enhancement
jgrandja
added
type: bug
|
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
force-pushed
the
fix-468
branch
2 times, most recently
from
552a4a0 to
83943b2
Compare
|
@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. |
|
@symposion There are too many touch points in the latest updates and I'm very confident that we can isolate the required changes to
For the "no client authentication included" use case, we can add a check here: 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 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. |
The token endpoint is not intended to be compatible with |
Understood. I will re-implement the simpler way. |
Current implementation does not include the WWW-Authenticate header when returning a 401 for missing/invalid credentials when attempting to access the token endpoints. Fixes-468 Signed-off-by: Lucian Holland <[email protected]>
|
@jgrandja This is as minimally invasive as I think I can get it. My residual doubt here is that I'm now applying the WWW-Authenticate header to all INVALID_CLIENT errors, which isn't quite as limited as we discussed on the original ticket. If we want to limit this to only cases where no credentials were provided or client_secret_basic was used, then I think either:
(2) feels pretty ugly to me; but (1) is a bigger change that will touch more classes. Personally I'm not sure that there's much harm in just leaving it as it is, given that Basic is the only Authorization header auth scheme that the default server supports, so I don't think we'd ever be spec-invalid doing this. But I know you had more reservations about this originally. Let me know what your preferred approach is here. |
|
Thanks @symposion. The latest changes are pretty close but I do see the dilemma in the failure handler and always sending back On a side note, I'm hoping to get this into a patch release but with the addition of |
There was a problem hiding this comment.
Thanks for your patience @symposion.
Please see review feedback.
| @@ -90,6 +90,8 @@ public final class OAuth2ClientAuthenticationFilter extends OncePerRequestFilter | |||
|
|
|||
| private final AuthenticationDetailsSource<HttpServletRequest, ?> authenticationDetailsSource = new WebAuthenticationDetailsSource(); | |||
|
|
|||
| private final String realmName; | |||
There was a problem hiding this comment.
Please remove realmName as the framework would not make much use of it. Furthermore, the implicit "realm" where the client credentials are authenticated against is the single instance of RegisteredClientRepository.
The "realm" parameter is mainly used for user-based authentication.
| } | ||
| else { | ||
| this.authenticationFailureHandler.onAuthenticationFailure(request, response, | ||
| new OAuth2AuthenticationException(OAuth2ErrorCodes.INVALID_CLIENT)); |
There was a problem hiding this comment.
Define private static final String MISSING_CLIENT_AUTH_ERROR_CODE = "missing_client_auth" and use that as the error code instead of INVALID_CLIENT. Then the authenticationFailureHandler can evaluate that specific error code and default to 401 WWW-Authenticate: Basic.
| OAuth2Error error = ((OAuth2AuthenticationException) exception).getError(); | ||
| ServletServerHttpResponse httpResponse = new ServletServerHttpResponse(response); | ||
| if (OAuth2ErrorCodes.INVALID_CLIENT.equals(error.getErrorCode())) { | ||
| httpResponse.setStatusCode(HttpStatus.UNAUTHORIZED); | ||
| httpResponse.getHeaders().set("WWW-Authenticate", "Basic realm=\"" + this.realmName + "\""); |
There was a problem hiding this comment.
Only return WWW-Authenticate: Basic when error code is MISSING_CLIENT_AUTH_ERROR_CODE OR when the HttpServletRequest contains the header Authorization Basic.
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
Related gh-468