OAuth with Azure Active Directory: Azure AD returns incorrect value for the State parameter after denying admin-consent scopes

Question

During OAuth interaction with Azure AD, it appears that Azure returns incorrect value for the State parameter after users deny grant for admin-consent scopes.

When constructing the URL for requesting authorization code from Azure AD via the Azure AD v2.0 endpoint https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize, let say I specify the State parameter as a+b. Then url encoding the State parameter value to a%2Bb and then put in the URL for requesting authorization code from Azure AD

If the request specifies scopes that require administrator consent and have not be granted in the past, Azure returns the following page as expected:

I was trying to verify my application logic for handling errors returning from Azure. So I denied this consent by clicking the Return to the application without granting consent link. After that, Azure expectedly returned an error response to my app's redirect URI. Azure populated the data in the HTTP body as follows:

Azure populated the State parameter value as a%252bb. This is not correct. The expected value should be a%2Bb - i.e. same as the value specified earlier when calling the Azure authorization code request endpoint as described earlier. It looks like Azure somehow performed a double URL encoding - in other words, encoding an already url-encoded State parameter, changing a%2Bb to a%252bb. (% was encoded to %25. In addition it is strange that B somehow became b)

It appears that Azure has this issue in the code path for handling users clicking the Return to the application without granting consent link for denying admin-consent scopes. For the other scenario of users denying user-consent scopes, it appears that Azure does NOT have this issue. Azure returns a proper value for the State parameter as illustrated as follows:

Answer 1

I tried again today. Looks like Microsoft has just removed the Return to the application without granting consent link. So the issue mentioned in this post earlier no longer exists.