Describe the bug We are integrating with an Oauth2 provider. I need to send the user's email as a "login_hint" additional parameter in the OAuth2AuthorizationRequest . I've done this by providing a custom OAuth2AuthorizationRequestResolver, and building a new OAuth2AuthorizationRequest from the resolved one, and adding my new additional parameters.
This works, unless the user's email contains a "+". In that case, the + is not encoded, and the provider replaces it with a space.
getAuthorizationRequestUri() says the value is MIME format, but buildAuthorizationRequestUri() uses encodeQueryParam() which uses RFC 3986, and does not encode '+' because it is in the sub-delims charset.
To Reproduce
JUnit demonstration test
```@Test
public void testMimeEncodedSimple() {
OAuth2AuthorizationRequest resolve = OAuth2AuthorizationRequest.implicit()
.authorizationUri("https://server.local/oauth2/v1/authorize")
.clientId("clientid")
.scope("openid", "profile", "email")
.additionalParameters(Map.of("nonce", "random"))
.attributes(Map.of("nonce", "nonce2", "registration_id", "server-idp"))
.state("value")
.redirectUri("http://localhost:8081/login/oauth2/code/server-idp")
.build();
Map
// .build() here uses
// Encode query parameter value according to RFC 3986
// private static String encodeQueryParam(String value) {
OAuth2AuthorizationRequest build = OAuth2AuthorizationRequest.from(resolve).additionalParameters(attrs).build();
// * <b>NOTE:</b> The {@code URI} string is encoded in the {@code application/x-www-form-urlencoded} MIME format.
String authorizationUri = build.getAuthorizationRequestUri();
assertFalse("should not contain + : " + authorizationUri, authorizationUri.contains("fred+bah@example.com"));
assertTrue("should contain %2B : " + authorizationUri, authorizationUri.contains("fred%2Bbah@example.com"));
}
``` Expected behavior encodeQueryParam() should use a mime-encoding that converts + to %2B.
Comment From: jzheaux
@sc-moonlight thanks for the report. Would you be able to provide a PR making this change?
Comment From: sc-moonlight
I'm investigating, and trying to wrap my head around the uri/url differences, to make sure this is the best choice.
Also while investigating a change, I found gh-7714 changes that might address my issue. We are still on SpringSecurity 5.2.4 for now, but if authorizationRequestCustomizer from 5.3 can address my issue, then I can force the upgrade issue here.
Comment From: jzheaux
Sounds great, @sc-moonlight. I will mark this as waiting-for-feedback. Feel free to update the issue with any changes you feel need to be made or to close it if you are satisfied.
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: spring-projects-issues
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.