Expected Behavior
As mentionned in OpenID documentation, Open ID Provider Configuration should only provide application/json.
As a result, ClientRegistrations shouldn't call these endpoints with anything else that application/json in Accept header.
Current Behavior
org.springframework.security.oauth2.client.registration.ClientRegistrations use default RestTemplate.
Default dehaviour is to add any supported media type as a request header... then it adds application/json... as well as application/xml with XML prior to JSON.
It works perfectly with most OpenID implementations and deserializers. But if OpenID Provider can also answer with XML, deserialization can be tricky, and don't work out of the box.
Context
Talking with a third-party OpenID Provider, which configuration may be wrong on the matter : the .well-known/openid-configuration path can answer in XML as well as JSON, depending on the Accept header.
Deserializing some XML lists is tricky, with different converters implementations.
Typical lists are "scopes_supported" :
"scopes_supported": [
"openid",
"tenants",
"roles"
]
which result in XML :
<scopes_supported>openid</scopes_supported>
<scopes_supported>tenants</scopes_supported>
<scopes_supported>roles</scopes_supported>
... converters tends to fail deserializing this list out of the box. But it should be useless considering specification don't allow XML.
I'm currently using spring-security-oauth2-client version 5.7.5.
Seems to work like a charm adding .accept(MediaType.APPLICATION_JSON) on requests, in org.springframework.security.oauth2.client.registration.ClientRegistrations
Comment From: sjohnr
Thanks for the suggestion, @mfrechePgest!
The OIDC specification clearly documents the response as containing Content-Type: application/json. However, I don't see the specification document the Accept header of the request. To clarify, are you suggesting that the use of a Content-Type header in the response implies an Accept header in the request even though it isn't documented? Or are you seeing it documented elsewhere?
Comment From: mfrechePgest
Indeed I didn't read such a thing in any documentation.
But that's the point of the Accept header, isn't it ? We use this header to negociate response Content-type.
To be fair, documentation don't tell we should send application/xml as Accept header, either 😅
From my point, it should only make sense to use Json accept header (or maybe none) in this case.
Once again, in my case the only real wrong behaviour is from my provider...