IIdentityServerInteractionService.GetAuthorizationContextAsync regression in 7.4.0

[cri5ti]

We are using the IIdentityServerInteractionService.GetAuthorizationContextAsync to determine the ClientId used by an application to slightly tweak the login experience.

In our OpenID client (Expo AuthSession) we list multiple scopes, e.g:
["openid", "profile", "offline_access"]

These are serialized into the returnUrl as:
scope=openid+profile+offline_access
(URL-encoded as scope%3Dopenid%2Bprofile%2Boffline_access)

Historically (up to 7.3.x), IdentityServer accepted + as a scope separator.
From 7.4.0 onwards, + is no longer accepted, scope validation fails, and GetAuthorizationContextAsync returns null.

This appears to be a regression introduced in: DuendeSoftware/products#2096.

Previously, ReadQueryStringAsNameValueCollection used QueryHelpers.ParseNullableQuery, which performs + to space decoding.
It now uses Uri.UnescapeDataString, which explicitly does not.

My question is:

• Is this intended behaviour? (i.e. previous versions were too permissive and non-spec compliant)
• Or is this an unintended breaking change / regression?

If this is intentional, we will raise the issue with Expo. Otherwise, we believe this change breaks existing clients that rely on application/x-www-form-urlencoded semantics.

EDIT: Having reviewed the spec, it seems the + encoding is valid in the returnUrl:

• Section 4.1.1 Authorization Request

The client constructs the request URI by adding the following
parameters to the query component of the authorization endpoint URI
using the "application/x-www-form-urlencoded" format, per Appendix B:

• Appendix B. Use of application/x-www-form-urlencoded Media Type

For example, the value consisting of the six Unicode code points
(1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN),
(3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN),
(5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded
into the octet sequence below (using hexadecimal notation):
20 25 26 2B C2 A3 E2 82 AC
and then represented in the payload as:
+%25%26%2B%C2%A3%E2%82%AC

[josephdecock]

Hi, and thanks very much for your detailed bug report and analysis!

You are correct, this is in fact a regression. The plus character is valid in these encodings, and it was not our intention to change behavior in this way. I am currently working on a fix. Look for IdentityServer 7.4.5 with this fixed in the next day or so.

[adamralph]

@cri5ti we've just released IdentityServer 7.4.5, which should fix this issue.

Please give it a try and let us know how you get on!

[cri5ti]

Thanks! The fix resolved the issue on our side 🙏
Really appreciate the quick fix for this regression.