Is content-type application/x-www-form-urlencoded required when calling user info endpoint with empty body?

[Joseph Heenan]

As per https://gitlab.com/openid/conformance-suite/merge_requests/785#note_256490283 - it turns out the existing OpenID Connect Core python certification tests (in particular OP-UserInfo-Header) make a request to the user info endpoint like so:

‌

2 do_user_info_request kwargs:{'state': 'LcaEMlJrGyE1ZG0B', 'method': 'POST', 'behavior': 'use_authorization_header'}
2 request {'body': ''}
2 request_url https://fapidev-rs.authlete.net/api/userinfo
2 request_http_args {'headers': {'Authorization': 'Bearer 8mZ80RhMMQq7j6-6WMh95s--xEYq4BTn1D8balXaI8Q', 'Content-Type': 'application/x-www-form-urlencoded'}}
3 http response url:https://fapidev-rs.authlete.net/api/userinfo status_code:200

or put more succinctly in HTTP speak

POST /api/userinfo HTTP/1.1
Authorization: Bearer 8mZ80RhMMQq7j6-6WMh95s--xEYq4BTn1D8balXaI8Q
Content-Type: application/x-www-form-urlencoded

<empty body>

I can’t find any spec reference that suggests the Content-Type: application/x-www-form-urlencoded must be sent.

If you don’t send the Content-Type header, we believe at least two OPs (Authlete, node-oidc-provider) fail the request.

The certification team would appreciate guidance from the Connect Working Group as to whether the java equivalent of this test should send the Content-Type header, or if the OPs are incorrect and should be fixed.

[Brian Campbell]

If a message is sent with no content, does the content have a type?

IMHO the test should not send the Content-Type header in this case and it’s erroneous to require it.

[Joseph Heenan]

Thanks Brian; I tend to agree.

The only thing that gave me pause for concern was the only two implementations we have easy access to test against (Authlete & node-openid-provider) both required the Content-Type: application/x-www-form-urlencoded (I have no real ability to easily check behaviour of other OPs despite trying to contact various vendors), at a minimum it seems likely this will be a common pain point when existing certified OPs test against the new tests.

[Takahiko Kawasaki]

Thank you for finding the bug. Authlete has fixed it.

https://github.com/authlete/java-resource-server/commit/195537e686a82e5b476a997f2220a3d7a0c060c9

General feedback: Because OIDC Core 1.0 Section 5.3 requires “The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token Usage [RFC6750].”, implementations try to extract an access token from (1) the Authorization header (RFC 6750 Section 2.1), (2) the request body (RFC 6750 Section 2.2) and (3) the query component (RFC 6750 Section 2.3). The easiest way to support (2) in JAX-RS applications is to use @Consumes(“application/x-www-form-urlencoded”) and @FormParam(“access_token”), but these annotations don’t work when the request does not include the Content-Type header or its value is not application/x-www-form-urlencoded. I don’t know the implementation of node-oidc-provider, but in general, web application frameworks provide a mechanism for developers to extract query parameters and form parameters seamlessly, and such mechanism may encounter the issue reported here when an HTTP request comes without the Content-Type header although its HTTP method is POST.

[Michael Jones]

Content type shouldn’t be required when there is no content.

[Michael Jones]

Joseph, is this now handled in the certification suite? If so, we can close this issue.

[Joseph Heenan]

Yes, the java tests do NOT send Content-Type: application/x-www-form-urlencoded (and have never done so) - this can be closed I believe.

[Michael Jones]

Closing, per @Joseph Heenan 's description of the resolution in the certification suite.