Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClientRegistrations should only accept application/json MediaType #12509

Open
mfrechePgest opened this issue Jan 10, 2023 · 2 comments
Open

ClientRegistrations should only accept application/json MediaType #12509

mfrechePgest opened this issue Jan 10, 2023 · 2 comments
Assignees
Labels
status: feedback-provided Feedback has been provided type: enhancement A general enhancement

Comments

@mfrechePgest
Copy link

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

@mfrechePgest mfrechePgest added status: waiting-for-triage An issue we've not yet triaged type: enhancement A general enhancement labels Jan 10, 2023
@sjohnr
Copy link
Member

sjohnr commented Jan 13, 2023

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?

@sjohnr sjohnr added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Jan 13, 2023
@mfrechePgest
Copy link
Author

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...

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jan 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: feedback-provided Feedback has been provided type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants