Lately I tried adding a secret and realized that it is not stored properly in the unconfirmed authorization code. When I saw that this has been fixed in SECOAUTH-122 I tried again immediately and it worked perfectly in Jetty and Tomcat, but in WebLogic the rest template call in OAuth2AccessTokenSupport.retrieveToken(MultiValueM ap<String, String> form, OAuth2ProtectedResourceDetails resource) fails with code 401 "unauthorized", which leads me back to the confirm access page again and again. This is the code:
The accessTokenUri is "http://localhost:7001/sparklr/oauth/authorize", the form contains grant_type=[authorization_code], code=[qdTweX], redirect_uri=[http://localhost:7001/tonr/dpcom/login] and the resource contains the client secret, as expected and exactly like in Jetty or Tomcat.
new OAuth2AuthTokenCallback(form, resource),
(List) Arrays.asList(new OAuth2AccessTokenMessageConverter())));
This is returned in the response body:
Does anybody have any idea why this fails in WLS when I use a client secret? Maybe this is a similar problem as in SECOAUTH-114, which results from a different (and most probably buggy) implementation of the filter chain in WLS.
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1 :
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.