Disallowed behavior for pushed authorization requests...

[pieterphilippaerts]

Hi all,

Not a major issue (I think), but I found some behavior in IdentityServer's PAR implementation that is explicitly forbidden by the standard.

Specifically, section 3 of RFC9126 says this about the "request" parameter:

Clients MAY use the "request" parameter as defined in JAR [RFC9101] to push a Request Object JWT to the authorization server. [..] Request parameters required by a given client authentication method are included in the "application/x-www-form-urlencoded" request directly and are the only parameters other than "request" in the form body (e.g., mutual TLS client authentication [RFC8705] uses the "client_id" HTTP request parameter, while JWT assertion-based client authentication [RFC7523] uses "client_assertion" and "client_assertion_type"). All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request.

It looks like IdentityServer doesn't strictly apply these guidelines. For example, the following request is allowed (tested on the implementation running on demo.duendesoftware.com):

POST https://demo.duendesoftware.com/connect/par
User-Agent: OAuch
Content-Type: application/x-www-form-urlencoded
Content-Length: 1834

client_id=interactive.confidential.jar.jwt&client_assertion_type=urn%3aietf%3aparams%3aoauth%3aclient-assertion-type%3ajwt-bearer&response_type=code&client_assertion=eyJraWQiOiJaekFqU25yYVUzYmtXR25uQXFMYXBZR3BUeU5mTGJqYnpnQVBiYlcyR0VBIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJpbnRlcmFjdGl2ZS5jb25maWRlbnRpYWwuamFyLmp3dCIsInN1YiI6ImludGVyYWN0aXZlLmNvbmZpZGVudGlhbC5qYXIuand0IiwiYXVkIjoiaHR0cHM6Ly9kZW1vLmR1ZW5kZXNvZnR3YXJlLmNvbS9jb25uZWN0L3Rva2VuIiwianRpIjoiNDNiNzFmMzkxYzAyNDYyOGI5ZDkxNjFhNjhjZWZiNmQiLCJleHAiOjE3NTAzNjIyNDksImlhdCI6MTc1MDI3NTg0NCwibmJmIjoxNzUwMjc1ODQ0fQ.iwsfYsizP0nA4fUpCCR3qgP2XrdQpy8Z2mrsPxE5P-sFFB7EsXskrEhlc2gULQC5hr8FtreuTNqVdNecYS_GHrLFNV5V_2zN4WGEImQL-BqxGwlmzEDAYGkEOIKTcMyyKZjxOcqI6tQb4t3v2BuAmDCtMTJKpVk6A3ncztDnKGbHGIlc8Uwafq2KslH4CPVZzf5ls562pV-c1X4_IipxEopHCScMpVc6zgrIvwuxV1sp5gw37T-TxNxb05UZMjicFgyRyAqsCtGjLTSH94wbI2sCFBkXSXMGp9DAnR9nD9v0b4V91szEYsf2pLfczfEmHZNxCcvGQvJE96UcF1awHg&request=eyJhbGciOiJSUzI1NiJ9.eyJjbGllbnRfaWQiOiJpbnRlcmFjdGl2ZS5jb25maWRlbnRpYWwuamFyLmp3dCIsInNjb3BlIjoib3BlbmlkIHByb2ZpbGUgYXBpIG9mZmxpbmVfYWNjZXNzIiwiY29kZV9jaGFsbGVuZ2UiOiJCWFpRSTc4R2FTWmh4WFRXZFd0YUIxampUQ1lFR2VUNVJGRE81SC1XYlJnIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vb2F1Y2guaW8vQ2FsbGJhY2siLCJzdGF0ZSI6Im9hdWNoX3N0YXRlX3ZhciIsIm5vbmNlIjoib2F1Y2hfb3BlbmlkX25vbmNlIiwiaXNzIjoiaW50ZXJhY3RpdmUuY29uZmlkZW50aWFsLmphci5qd3QiLCJhdWQiOiJodHRwczovL2RlbW8uZHVlbmRlc29mdHdhcmUuY29tIiwiaWF0IjoxNzUwMjc1ODQ0LCJleHAiOjE3NTAzNjIyNDksIm5iZiI6MTc1MDI3NTg0NH0.sanAp4vUvpH9yhWtyLb-xZvz2GAxb1Sp4W9PfJMS1BMTdCZr6a55dWwGKSyHvvQPEzdK6harK9vi_5w5VQr5q03T__HHNz8mMGZT17soXFTIeo4CqtaQu0cN4wwlVG2pLux2K9j5u00zUXwtw7gj4c1gqMS2qIoY04lWPjDuK0IcLGEOPIVePoSs0U4sNKiavkv4cmZQOohoB87ZqF4nnrk0xdq5TiFSp7K5kLZv0A9ZiuV1_AiH4AvkmK_sq-noTCn8h2QxK_agJfB982a3yK-KGzwfXqqqVbxKFrO8VBpQBHb4EWL57GDqUBgBhPXcVRJLcIQ4C6jB4XeY1TJLHQ

Notice that the response_type parameter is included in the request directly (which is not allowed) and that it is not present in the JWT of the request parameter (which is mandatory).

[wcabus]

Thanks for bringing this to our attention! It does indeed not seem to be a major issue, we will fix this behavior in a future release.

If you happen to find similar issues with any of our products, feel free to report them here. For security vulnerabilities or more sensitive issues, please use our contact form instead.