Non-URI resource indicators

[Henri Mikkonen]

The current resource -parameter validation is performed as mandated by RFC 8707 section 2 (also referenced from issue 371).

That makes sense from the spec perspective, but we have noticed that this strict validation rule is not very well in-line with the other parts of the OAuth2/OIDC stack. I mean, for instance OAuth2 RFC 6749 and OIDC core allow client_id to be just string instead of URI. That’s why we started thinking if parsing of AuthorizationRequest should also allow non-URI resource parameters at least with some special configuration. By special configuration, I mean for instance a flag to the parse-method, that would parse the resource-parameter to some other class variable as the current List<URI> one.

We understand that this would violate the RFC 8707, but if the non-URI resources were allowed with some non-default configuration, the violation would only be done on purpose. This way the authorization requests could indicate a non-URI client_id to be included in the audience of the access tokens to be issued in the sequence.

What do you think about this idea? Are you aware of any discussion regarding this topic?

[Vladimir Dzhuvinov]

Hi Henri,

We thought how to go about this for a while. The code exception to support String resources will not be trivial because it requires the field, constructor and builders in the base AuthorizationRequest and the AuthenticationRequest to be changed as well.

Two possible workarounds:

• Before the request gets parsed, prefix the parameter name(s) with x_ , e.g. as x_resource and then extract them from the parsed request as a custom parameter.
• Prefix the parameter value(s) with a urn:client_id:, e.g. urn:client_id:123 , which will parse successfully as a URI.

‌

[Henri Mikkonen]

With v10, I had successfully used the first proposed approach by fetching the query string via HTTPRequest.getQuery(), switching the resource parameter name in the query string into a custom one, and then setting it back to the object via httpRequest.setQuery(customisedQuery).

After upgrading to v11 I noticed that this change https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/commits/dedfc0628e1a3d56d786c1205f556ac5e7ddd49d has deprecated that method. Actually it’s not just deprecated, but doesn’t work anymore since the setQuery(..) method appends the customised query into the existing query (with GET-method).

With v11, I don’t find a fluent way to customise GET request parameters anymore. I see that the HTTPRequest.url property is mutable, but I don’t think the URL class any manipulation methods for the request parameter either? Would it be possible to add setURL(..) method to the HTTPRequest class and/or some other way to manipulate the query parameters? Or have I missed an existing way to do it in v11?

[Vladimir Dzhuvinov]

Hi Henri,

The HTTP message classes got refactored because the request parameter handling didn’t permit setting both query and form params in a proper. Actually it did, but was ugly :)

With the updated API use getQueryStringParameters() and appendQueryParameters. This means the HTTPRequest object will need to be recreated with the updated resource param(s).

Let me know if you have questions.

[Henri Mikkonen]

Hi Vladimir,

Thanks for your explanation! I refactored my code to exploit HttpServletRequestWrapper for manipulating the query parameters before converting it into HTTPRequest. For the POST parameters, I used get/setBody to achieve the same.

From my perspective this issue can be closed, unless you want to keep it open for providing some alternative methods for accepting non-URI resource parameters.