Bug with client_secret and clientauthenticationscheme header

[ahoehn]

If I use the client authentication scheme header (default) with a client id and client secret i allways get a "Bad client credentials" error. If i set the client authentication scheme to query then the same configuration works.
This sounds like a bug to me. I use 1.0.0.RC3

Tested with the following conifguration:

@Bean(name = "publicRestTemplate")
	public OAuth2RestTemplate createOauthRestTemplate() {
		ClientCredentialsResourceDetails rd = new ClientCredentialsResourceDetails();
		rd.setAccessTokenUri("http://localhost:8080/myapp/oauth/token");
		rd.setClientId("myapp-application");
		rd.setClientSecret("ApplicationSecret");
		rd.setGrantType("client_credentials");
		rd.setClientAuthenticationScheme(AuthenticationScheme.query);
                //rd.setClientAuthenticationScheme(AuthenticationScheme.header); Remark: not working
		OAuth2RestTemplate oAuth2RestTemplate = new OAuth2RestTemplate(rd);
		List<HttpMessageConverter<?>> messageConverters = new ArrayList<HttpMessageConverter<?>>();
		messageConverters.add(new MappingJacksonHttpMessageConverter());
		oAuth2RestTemplate.setMessageConverters(messageConverters);
		return oAuth2RestTemplate;
	}

Server config:

<bean id="clientDetailsUserService" class="org.springframework.security.oauth2.provider.client.ClientDetailsUserDetailsService">
		<constructor-arg ref="clientDetails" />
	</bean>

<oauth:client-details-service id="clientDetails">
		<oauth:client client-id="myapp-application"
			authorized-grant-types="authorization_code,client_credentials" secret="ApplicationSecret"
			authorities="ROLE_USER" />
</oauth:client-details-service>

Or is there any missconfiguration?

[Dave Syer]

I don't think there is any bug here. You need to upgrade to a full release, but even back in RC* days you would need to handle the authentication for the /token endpoint yourself explicitly in the Spring Security filters. Please see the sparklr sample for a guide (hint: it uses <basic/> authentication).

[davesosb]

If you use the header scheme, basic authentication filter successfully authenticates the request. If you use query scheme, ClientCredentialsTokenEndpointFilter successfully authenticates the request, however, when you have both enabled and you use header scheme, Basic filter successfully authenticates but fails in ClientCredentialsTokenEndpointFilter since there is no request parameter "client_secret"; according to the code ClientCredentialsTokenEndpointFilter should not be applying since there is already a successful authentication in SecurityContext. If I remember well what I described happened to me a bit ago

[Dave Syer]

I think this is fixed if you use the TokenEndpointAuthenticationFilter in the latest codebase (1.0.2 is just about to be released when I get a minute to push the button). I would recommend not using ClientCredentialsTokenEndpointFilter anyway, but if you need that *and* the <basic/> auth then probably the new filter will help.