-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query parameters in authorization-url are double-encoded #7871
Comments
A further analysis reveals two problems:
The correct way forward should be:
At no point should the authorization URL be treated as a template URL. The implication (aside from fixing the double encoding) would be that the redirect_uri is encoded differently. Instead of:
it would become:
This is correct according to the standard (RFC 3986). The referred backward compatiblity issue most likely has never been revelant for IdP implementations. And for a security relevant process like OAuth 2.0, correctness should be valued higher than compatiblity with broken software. |
A small update: Before PR #6299, the redirect_uri was fully encoded. So for this particular aspect, the proposed approach would restore the old behavior without breaking what the PR was supposed to fix in the first place (support for query parameters). |
Even if there is some need for backward compatibility, I'd suggest the correct behavior described above be the default and any special cases require customization. |
BTW: This fix is important to support the OIDC claims parameter (see https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter). It mandates a properly encoded JSON data structure. |
It seems that I misunderstood the backward compatibility issue: The characters So fixing this issue and being fully standard's compliant does not change the current encoding of the |
If the authorization URL in the OAuth2 provider configuration contained query parameters with escaped characters, these characters were escaped a second time. This commit fixes it. It is relevant to support the OIDC claims parameter (see https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter). Fixes gh-7871
Summary
If the autorization URL of a OAuth 2.0 provider contains query parameters with URL encoded characters, they are encoded again and the request is rejected by the IdP.
Example: If the authorization URL in
application.yml
is configured as:authorization-uri: 'https://iam.abc.com/idp/oauth2/authorize?claims=%7B%22urn%3Aabc%3Aplace_of_birth%22%3Anull%7D
Then the resulting URL becomes (somewhat shortened):
https://iam.abc.com/idp/oauth2/authorize?acr_values=quo1&claims=%257B%2522urn%253Aabc%253Aplace_of_birth%2522%253Anull%257D&response_type=code&client_id=c1&scope=openid%20profile%20email&state=83l9MUgoab0w&redirect_uri=http://localhost:8081/login/oauth2/code/abc&nonce=w4VgoHfH9f71'
The
claims
parameter is now double encoded. The IdP doesn't understand it anymore and rejects the authorization request.Actual Behavior
The query parameter value is double encoded and no longer valid for the IdP.
Correct value in configuration:
claims=%7B%22urn%3Aabc%3Aplace_of_birth%22%3Anull%7D
Invalid value in request:
claims=claims=%257B%2522urn%253Aabc%253Aplace_of_birth%2522%253Anull%257D
Expected Behavior
No double encoding should be applied. The query parameter value should be retained without changes.
Correct value in configuration:
claims=%7B%22urn%3Aabc%3Aplace_of_birth%22%3Anull%7D
Correct value in request:
claims=%7B%22urn%3Aabc%3Aplace_of_birth%22%3Anull%7D
Notes
If an invalid URL without URL encoding is used::
claims={"urn:abc:place_of_birth":null}
the resulting URL is invalid as well (and rejected by the IdP):
claims={%22urn:abc:date_of_birth%22:null}
Furthermore, if URLs were to be entered without encoding the query parameters, many parameter values could not be entered as the URL would no longer be parseable.
I am aware of issue #5760 and the associated PR #6299. Unfortunately, it fixes the problem only partially.
At first look, it seems that the root cause is at OAuth2AuthorizationRequest.java, line 395 where
UriComponentsBuilder.fromHttpUrl
is called. This method is for parsing URL templates that contain substitutable components and has documented limitations regarding query parameters. Since substitutable components are not needed, a more suitable method should be used instead.Configuration
application.yml
build.gradle
Version
Sample
In addition to the above configurations, the following code completes a sample. There is no custom
WebSecurityConfigurerAdapter
. The out-of-the-box configuration sufficient.DemoApplication.java
HomeController.java
The text was updated successfully, but these errors were encountered: