Forum Discussion
MicrosoftAzure AD B2C authorization code and refresh token size increase update
Update September 11, 2023: This post is irrelevant anymore
As part of ongoing security improvement efforts in Azure Active Directory (AAD), part of Microsoft Entra, Azure AD B2C will be rolling out a format change that increases the size of OAuth 2.0 (and OpenID Connect) authorization code and refresh tokens returned to your application. If your application is configured to accept the OAuth2 authorization code as query string parameter or URL fragment, this change might impact users in the following scenarios:
Users with old web browsers such as internet explorer may exceed the URL length limit.If your application runs on web servers, behind firewalls or reverse proxies with low URL length limits or configuration.
The OAuth2 (and OpenID Connect) protocol specifies three response modes which specify how the authorization code is returned to your application. With the query and fragment mode the authorization code is returned as a query parameter or fragment of the URL. In the form_post mode, response parameters will be encoded as HTML form values that are transmitted via the HTTP POST method and encoded in the body. For information, check out the OAuth 2.0 authorization code flow in Azure Active Directory B2C article.
To mitigate URL lengths issues:
For web applications, we recommend using OAuth2 response_mode set to form_post, to ensure the most secure transfer of tokens to your application.For single page application with authorization code flow and PKCE, reduce the number of claims omitted to your application. In the user flows, and custom policies remove claims that are unnecessary for your app. You can use the user info endpoint to return claims about the authenticated user. This will minimize the size of the authorization code and the refresh token.This change should not affect device-installed apps, such as mobile and desktop apps.
The change also impacts the size of the refresh token. MSAL library caches a token after it has been acquired. For web applications with in-memory cache, or a distributed token cache, make sure your cache system can handle the size of the refresh token, or reduce the size of the refresh token as described in the previous section.
Yoel
- yoelh Hi - Is there an official announcement or statement from Microsoft regarding this release or rollback - or any future release like this one that we can subscribe to?
- This change should not affect device-installed apps, such as mobile and desktop apps.
I call bullsh*t... It broke my winforms app. Azure support had zero visibility of this change and couldn't help at all. Useless! Now 2 days after I've resolved this I stumble on this.
Poor effort! - This breaking change was poorly communicated to say the least.
yoelh Wow this caused us a lot of trouble. We have some desktop apps that lets users log in using Azure B2C. This morning our support desk was overwhelmed with calls of customers not being able to log in due to this change. We found out that customers running an older version of our software where primarily impacted by this change. Customers running newer versions where not impacted. Turned out new version use a newer version of the MSAL NuGet package, in which support for this change was introduced: Release 4.35.0 · AzureAD/microsoft-authentication-library-for-dotnet (github.com)
Limits on URL length in embedded browsers was causing errors with auth code. Applications will not fail on the embedded browers due to the limitation. See issue #2743
We would very much like to know what we should have done to prevent this. Is this blog post the only way of communication regarding this update? What will Microsoft do in order to prevent this from happening again since a lot of replies mention the poor communication regarding this change.
- This gave us intermittent errors to full outage over a 24hr window as I guess this update was rolled out.
We have implemented the IIS web.config values as a workaround upping the max lengths for now.
It does feel like a breaking change that should have been communicated and ideally been an option to enable this new more secure way rather than taking out our applications. - I have the same problem and updated the web.config, but I analyzed a better solution removing all claims, and can't get a minor code, that didn't work.
- For the next poor soul to find this:
We found a way to increase the supported size in IIS in a fairly ancient StackOverflow post:
https://stackoverflow.com/questions/8159321/request-exceeds-the-configured-maxquerystringlength-when-using-authorize
Successful solution is:
In the root web.config for your project, under the system.web node:
<system.web>
<httpRuntime maxUrlLength="10999" maxQueryStringLength="2097151" />
...
In addition, I had to add this under the system.webServer node or I got a security error for my long query strings:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxUrl="10999" maxQueryString="2097151" />
</requestFiltering>
</security>
...
It is critical that you update the values in BOTH web.config and system.web.
The suggestion to change response_mode to "form_post" couldn't be used for us because we are using a 3rd party module to handle the OIDC login, and it only support "query".
And not to be over the top... but I can't leave without encouraging the B2C engineering team to take some more steps next time there is a breaking change. Since we are paying for this service, I think the following is a reasonable expecation:
1. The standard Azure change notification email that goes out when updates are planned
2. The Azure B2C “What’s New” section in the Azure Portal
3. For a BREAKING change such as this…
a. Every B2C admin should have been specifically targeted with several emails before rollout
b. There should be a clear explanation of how to test your application BEFORE go live
c. There should be a complete list of mitigation steps, which was not the case. In our case IIS and Dotnet themselves – Microsoft products, as you know – are what broke. Not 3rd party solutions. Microsoft solutions.
Even now… AFTER rollout of this breaking change… the Azure B2C “What’s New” is not updated. - Thank you for the update, Alex
- Why was this not communicated in advance and in a better place than this hard to find blog post?? This broke all our apps for all users out of nowhere. Can MS please offer additional information about this? This is an auth code, not an access token, why does it have to be this huge?
mless340 we opened a support ticket, got confirmation that MS is rolling back customers - we're now waiting on a confirmation so our users can log in again
stijnsymons did the rollback resolve your issue?
- We are experiencing major issues with our Electron based applications.
None of the Windows-based browsers are opening our Electron application anymore due to the length of the deeplink which includes the auth code. We do not experience this on our macOS, Android and iOS applications.
