Malformed "Accept" header sent in requests to OIDC Provider

137 Views Asked by At

We use Pac4j v5.7.0 in Magnolia CMS for our SSO module.

When requesting the configuration metadata of an OIDC Provider (a Content-type: application/json document), Magnolia sends the following Accept header:

text/html, image/gif, image/jpeg, *; q=.2, /; q=.2

This breaks the spec in two ways:

  1. Breaks https://www.rfc-editor.org/rfc/rfc9110.html#name-accept with the content-type *
  2. Breaks https://www.rfc-editor.org/rfc/rfc9110.html#quality.values with the q value of .2

This results in complying servers returning a 406 (content negotiation) error and Magnolia not getting returned the requested OIDC configuration metadata.

We traced it down and found Pac4J seems to be using standard java.net.URLConnection and unfortunately the Accept header we are seeing is the default for it. Here is what it is sent when doing a simple: new URL("http://localhost:8888").connect()

GET / HTTP/1.1 User-Agent: Java/17.0.6 Host: 127.0.0.1:8888 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive

And unfortunately, as we can see in https://github.com/pac4j/pac4j/blob/master/pac4j-core/src/main/java/org/pac4j/core/resource/SpringResourceHelper.java#L52-L56, Pac4J is not setting or changing any of the default headers before opening the connection and sending the request.

If the above analysis is correct, it means that Pac4J is breaking the HTTP standards and will be unable to contact any OIDC server respecting Content Negotiation "protocol".

A quick look at the commit history tells me that it may be quite recent... They introduced the SpringResourceLoader/Helper classes that may be responsible for that only recently (3 months ago) -> https://github.com/pac4j/pac4j/commit/bebd578596b11916b531c5e7da7ed4ba3d75c479

For 5.7.0 everything happens between these lines: https://github.com/pac4j/pac4j/blob/5.7.x/pac4j-oidc/src/main/java/org/pac4j/oidc/config/OidcConfiguration.java#L175-L195

Thanks in advance

Rich G

Expecting the response header to conform to standards

1

There are 1 best solutions below

9
jleleu On

I guess you have a problem in v5.7 although you referenced a commit from v6.

The commit has been introduced in the future v6 (not yet GA released) to replace the DefaultResourceRetriever (from the Nimbus library) by the SpringResourceHelper (in the pac4j-core) to be able to (re)load the metadata from any Spring resource (resource:, classpath:, file:, http:).

In both cases, they rely on URLConnection so they should have the same problem.

I just committed: https://github.com/pac4j/pac4j/commit/3a21347069b0de186a4269d058ac60988d587c73

Can you test again with the 5.7.1-SNAPSHOT version (in the Sonatype snapshots repository)? Thanks