behaviour of AS when client passes different values in request object vs OAuth 2.0 request syntax

[Joseph Heenan]

As I read the specs currently ( https://openid.net/specs/openid-connect-core-1_0.html#RequestObject ) , clients can pass different values inside and outside the request object to the authorisation endpoint, and the server must accept them (and use the value inside).

This seems unnecessarily complex to me.

I cannot think of a valid reason for a client to pass values that are different.

I can imagine that in some cases using different values could cause confusion that gives rise to a security hole.

I am tempted to believe we should require the AS to reject the request in this case.

[Joseph Heenan]

https://openid.net/specs/openid-connect-core-1_0.html#RequestParameterValidation is more explicit:

If the same parameter exists both in the Request Object and the OAuth Authorization Request parameters, the parameter in the Request Object is used.

I am not 100% sure if that language prevents an AS rejecting a request when values differ.

[Brian Campbell]

Nat had this idea that's kinda captured in that section that one might have some values in the request object and some outside so as to facilitate a "pre-signed (and possibly pre-encrypted) Request Object value to be used containing the fixed request parameters, while parameters that can vary with each request, such as state and nonce, are passed as OAuth 2.0 parameters."

I don't think that's turned out to be used much, if at all. And the complexity and potential security holes has been raised. As a result, the soon to be RFC that defines Request Object functionality for vanilla OAuth is stricter and arguable less complex where in https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-4 it says that all the authorization request parameters have to be in the signed request.

The way these two standards around basically the same functionality have evolved makes implementing rather tricky.

I think from a pragmatic standpoint, FAPI should somewhere say that only the values inside the singed request object should be used or relied on. But what to do with regular parameters (ignore them or reject the request with an error) is an AS implementation or policy decision.

[Joseph Heenan]

Thanks Brian.

FAPI should somewhere say that only the values inside the singed request object should be used or relied on

I think we do basically say that already.

But what to do with regular parameters (ignore them or reject the request with an error) is an AS implementation or policy decision.

The only slight issue I have with this is that undefined behaviour makes it harder to write a test in the conformance suite for it. (ie. it's much easier to write the test for what happens when the client does pass differing values inside & outside the request object if the outcome is defined.)

[Brian Campbell]

That's a fair point. Just spitballing though, the behavior is still defined effectively as "don't use the values outside the request object", which is admittedly a little more tricky to test for but I think still possible. For example, a test could pass two different values for state, one in the request object and one as a query parameter and check that the value from inside the request object is passed back in the authorization response (whether the response is successful or an error).

[Joseph Heenan]

Yeah; this is something we do for other points in the specs that don't tightly define their behaviour. Tests that have two (or more) possible outcomes mean we have to provide a longer description to the user doing the test as to what they might/should see, and it also tends to result in a much longer conversation with the integrator when they fail the test - not helped by the fact that if it's a hard failure it won't be returned to the test suite and the user will have to screenshot it.

It's certainly not impossible to test, but I would tend to argue that it is best avoided where possible.

[Dave Tonge]

@josephheenan pls can you propose some text, thanks :-)

[Joseph Heenan]

So reading on in the document Brian mentioned, the next section https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17#section-5 contains:

The client MAY send the parameters included in the request object duplicated in the query parameters as well for the backward compatibility etc. However, the authorization server supporting this specification MUST only use the parameters included in the request object.

FAPI part 2 currently says:

shall require that all parameters are present inside the signed request object passed in the request or request_uri parameter;

So I think my proposal would be to reword this as:

shall only use the parameters included in the signed request object

which brings our wording into line with the oauth draft. I think it gives rise to the same effect so it's not a normative change that would cause interoperability issues.

I don't know if this clearly defines the behaviour when parameters are present with different values outside the request object, as it depends on your interpretation of "use". I think I could form an argument that the AS "used" the parameter if it returned an error due to the parameter being different outside the signed request object, and that ASs must hence not return errors for non-matching parameters, but I'm not sure that was the authors' intention.

[Dave Tonge]

I like that proposal

[Dave Tonge]

Merged in josephheenan/fapi/params-inside-req-obj (pull request #99)

FAPI-RW: Update wording to match jwsreq RFC

This is a minor clarification that is really non-normative but is slightly easier to read and more obvious how to implement, and matches the jwsreq draft.

closes #189

Approved-by: Brian Campbell [e-mail] Approved-by: Dave Tonge [e-mail]

→ <<cset f90ede694fc2>>