Repository navigation
client_secret_basic authentication failures should return challenge #18285
Description
Activity
- changed the title
[-]Respond with authentication scheme on failed client authentication[/-][+]Respond with authentication scheme when client authentication fails[/+]on Oct 25, 2021 Hi @jgrandja , the latest version of OAuth 2.1 is
draft-ietf-oauth-v2-1-04, so perhaps you could update the link address in the original post to this: 3.2.3.1. Error ResponseReacted by Joe GrandjaThanks for your interest @Enkosz. This enhancement hasn't been planned for a specific release since it's lower priority.
However, if you would like to work on it we can schedule it whenever it is done.
@jgrandja You've closed my ticket #1873 as a duplicate of this one, but this ticket is a low-priority enhancement. I'd like to argue that the current behaviour is a bug - since it's in direct violation of both the HTTP spec and the OAuth spec; and it's not entirely insignificant since it means that many http clients, including at least Apache Commons and the .NET default http client - will, with their default settings, fail to authenticate for a client_credentials grant using http basic. This is a very common use case with very common libraries and it's actually quite non-obvious what's wrong at first glance. After upgrading from the old
@EnableAuthorizationServerimplementation to the new Spring Authorization Server this caused several of our customers to experience outages of their live services due to the (spec-incompliant) change in behaviour.I'm happy to submit a PR - I believe the fix is fairly trivial - if you agree that this is reasonably important.
Reacted by Martin Ashby@symposion The
WWW-Authenticateresponse header was never implemented when client basic authn was implemented so that's why this was labeled as an enhancement. However, after reviewing the spec, I agree this is a bug since this MUST be implemented. I've changed it to a bug and scheduled it for next release.Would you be able to submit a PR for this fix?
@jgrandja I'd be happy to have a stab at implementing this, it doesn't seem especially complicated. Before I do, I'd like to understand why this behaviour was changed from the original implementation in the old AuthorizationServerSecurityConfigurer. In that previous auth server implementation, the default behaviour was to use BasicAuthenticationEntryPoint with a default realm name of
oauth2/client. It seems like when re-implementing a deliberate choice was made to use HttpStatusEntryPoint instead... was there a reason for that? Or did it just get lost in the move?Related: is there any reason why we can't assume that it's a valid default setup to always issue a challenge with the Basic scheme? The spec says that the server should respond with the same scheme as any specified in the Authorization header of the request, but AFAICT out of the box SAS doesn't support anything other than Basic for this type of authentication (obviously it support other modes of auth such as JWT or POST parameters but these don't use the Authorization header)
Providing that this is configurable - and it should always be possible for users to supply their own AuthenticationEntryPoint - I think this seems like a reasonable default. If users extend the server to support other schemes for the Authorization header when authenticating clients, then obviously they'll have to customise the AuthenticationEntryPoint
I'd like to understand why this behaviour was changed from the original implementation in the old AuthorizationServerSecurityConfigurer
Spring Authorization Server was a complete re-write and therefore you can't rely on the same behaviour as the legacy framework. As already mentioned, the
WWW-Authenticateresponse header was not implemented whenclient_secret_basicwas implemented.is there any reason why we can't assume that it's a valid default setup to always issue a challenge with the Basic scheme?
To be clear, the
WWW-Authenticateresponse header should only be returned when theclient_secret_basicauthentication method is used.14 remaining items
Yes, this would fix the problem.
Excellent. As far as 2. goes (no client auth) there might be some side effects with the new default but we'll work through it and figure it out.
to provide a customisation hook for OAuth2ClientAuthenticationFilter so that the behaviour in onAuthenticationFailure can be controlled
This is already possible. See Configuring Client Authentication and the
clientAuthentication.errorResponseHandler(), which is anAuthenticationFailureHandler.I'm very happy to have a stab at implementing this if you agree.
That would be great. Thanks.
Reacted by Martin Ashby- added a commit that references this issue
on Apr 14, 2025 - changed the title
[-]Respond with authentication scheme when client authentication fails[/-][+]client_secret_basic authentication failures should return challenge[/+]on Apr 18, 2025 - added a commit that references this issue
on Apr 18, 2025 Reverted via c624d0a908af0b2a9314021e1377332ed3370661
This issue was transferred from spring-projects/spring-authorization-server (see spring-authorization-server#2195)
Hey, just wondering, what happened here? Why did this fix get reverted? I might be missing something but none of the relevant tickets/commits seem to have much in the way of explanation of what happened here?
@symposion Please see this comment
As per section 3.2.3.1. Error Response:
We should respond with the required authentication scheme when a client fails authentication.