Azure AD B2C authorization code and refresh token size increase update

[yoelh]

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

[#2]

@KStuber  Sure, here you go, please make sure to add / extend those blocks in the right place:

<system.web>
    <httpRuntime maxUrlLength="4096" maxQueryStringLength="4096" />
</system.web>

<system.webServer>
    <security>
      <requestFiltering>
        <requestLimits maxUrl="4096" maxQueryString="4096" />
      </requestFiltering>
    </security>
</system.webServer>

[#3]

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...

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.

[#4]

@Florian Wachs Thank you! That worked great. We did see URL lengths in the 5k-6k range, so we just had to bump up the values to accommodate. I really appreciate the reply!

[#5]

@eschillercourtalert Are you able to resolve this issue? Any update from Microsoft? We are facing the same issue with our Windows application. Thank you

[#6]

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.

[#7]

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.

[#8]

@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.

[#9]

This breaking change was poorly communicated to say the least.

[#10]

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!

[#11]

Thank you for the update, Alex

[#12]

@stijnsymons did the rollback resolve your issue?

[#13]

It appears it has been rolled back, with the AuthCode now at around 900 characters.

[#14]

Do you know if there have been any official communication from ms about the roll back? :) @paulvancoller-appsure 

[#15]

@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?

[#16]

Unfortunately I am not aware of any official communication about the rollback.

[#17]

@User20230420 there were two things we did to address this issue:

1) Opened a ticket with Microsoft, eventually they temporarily rolled back this change to my tenant. No word when the change will be permanently made

2) Update the version of Microsoft.Identity.Client nuget package on the desktop application. This addressed the issue until Microsoft rolled back the change

[#18]

@yoelh bump