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

Issue #1137 resolved
Joseph Heenan created an issue

As per - 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
2 request_http_args {'headers': {'Authorization': 'Bearer 8mZ80RhMMQq7j6-6WMh95s--xEYq4BTn1D8balXaI8Q', 'Content-Type': 'application/x-www-form-urlencoded'}}
3 http response url: 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.

Comments (9)

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

  2. Joseph Heenan reporter

    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.

  3. Takahiko Kawasaki

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

    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.

  4. Joseph Heenan reporter

    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.

  5. Log in to comment