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]

@yoelhThis change is causing errors within our OIDC Code Flow client application.  The "location" header in for a random AD authorization code 302 redirect is 4729 bytes!  The code parameter itself is 4643 bytes long!  My understanding of authorization codes is that they should be small and opaque and be a reference user state held within the Identity Provider, not an encoding of the state itself.

[#3]

@yoelh This change appears to broken all our Desktop applications that use MSAL .net (Microsoft.Identity.Client) to authenticate against our Azure B2C tenant. The .net exception our users are receiving is:

Exception: Microsoft.Identity.Client.MsalClientException
Message: The browser based authentication dialog failed to complete. Reason: The protocol is not known and no pluggable protocols have been entered that match.
Source: Microsoft.Identity.Client

[#4]

@yoelh this seems to have been partly rolled out yesterday, it caused intermittent issues with our SPA (using PKCE) as the querystring length returned is longer than the max default in .Net core.  Assume MS have load balanced between old (small) version and new (large) version.

As it was intermittent it was hard to track down this change as being the cause, we're struggling to find any release notes around this which would have allowed us to pre empt any issues.

[#5]

@yoelh 

This was raised as a critical incident yesterday (18/4) since people around the globe could not log in to business critical applications using Azure AD B2C. We noticed that the application error appeared when the code query parameter was too long.

At least we know the reason, now it's a matter of fixing it...

[#6]

Hi @yoelh. As part of ongoing security improvement efforts in Azure Active Directory (AAD), part of Microsoft Identity Platform, Azure AD B2C is rolling out a format change that increases the size of OAuth 2.0 (and OpenID Connect) authorization code and refresh tokens. This change may impact applications that use Azure AD B2C if they have size limitations for storing tokens. The general recommendation is to ensure that applications are prepared to handle larger tokens. To address this change, follow these steps: Ensure that your application can handle larger authorization and refresh tokens. The exact size may vary, but it's important that the application can handle tokens significantly larger than the current ones. Update your application, if necessary, to support larger tokens. Test your application to ensure it works correctly with larger tokens. Consider testing in a development or test environment before deploying the changes to the production environment. Microsoft usually provides notices and detailed information about these changes before implementing them. Therefore, it's important to stay updated with Microsoft announcements and update your applications accordingly.

[#7]

Completley broke mission critical applications yesterday and today @yoelh . I found this document while researching after I found out that the response codes are sometimes extrem long. Our awesome team managed to configure the servers (IIS) to mitigate the issue. This is very disturbing because this article seems to be the only mention of this change. I´m quite sure that many more people around the globe are riddled why their apps are "broken" until they find this article.

[#8]

Chiming in to confirm the token size increased in a couple of B2C tenants and did cause application down-time because the WAF max URL size is 2KB and we're seeing 3KB tokens.
Confirming also that this blog post is the only mention we've seen of this new behavior. This change doesn't, for example, appear on the Azure Updates page. Not what we expect for enterprise services.

[#9]

@yoelh 

For all those who encounter this issue on Azure web apps, we had to modify the web.config to override the request limits:
<requestFiltering>
    <requestLimits maxUrl="10999" maxQueryString="2097151" />
</requestFiltering>

For those who run a nodejs server under IIS, you will also need to increase the size of the http headers in the iisnode module:
<iisnode nodeProcessCommandLine="node.exe --max-http-header-size 81000"/>

[#10]

@hebboss Thanks for the details.

We run Angular Apps through Azure App Services using Node.js. We seem to be suffering the same issue where the length of the query parameters exceeds some sort of limit.

Any idea where we can bump this limit up with Node in App Services?

Thanks

[#11]

I am trying to understand in what world it makes sense to have auth codes that are a couple thousand characters in length. Why is Azure B2C using an encrypted JWT instead of an opaque reference token like every other OIDC Provider out there? You guys have selected a size of token that makes it impossible for your authorization code responses to be ingested using the default settings for your own products such as IIS. Our organization's WAF has a hard limit on the maximum URL size. We are in the process scrambling to implement a fix meanwhile our customers who use Azure B2C as their OP are unable to authenticate into our products while customers who use Ping, Okta, and others are just fine. We haven't had to keep track of the OP in use by our customers, because it really shouldn't matter as the OP is either in spec or they are not, and configuration of SSO is self service. You guys have created a mess for SAAS vendors out there because of a very poor design decision that lead to more poor decisions that OPs shouldn't have to worry about.

[#12]

@yoelh  Thanks for the post. However I believe this should have been communicated in a better-way. Perhaps next time give enterprises a larger notice period to properly analyse the impacts and develop a fix. Please look into sending  an email to your clients detailing the changes with the timelines , thereby sparing them the anxiety .

[#13]

We seem to be having the same issue for React Apps through Azure App Services using Node.js. Adding your suggested <requestFiltering> and <issnode> elements did not resolve the issue.

[#14]

It´s been great fun tracking down a web cookie size limitation error in our application of the last 24h only to find that MS has changed this with no prior warning, no way of disabling this change (at least for a while). We now have to rewrite auth related code while customers are unable to log in. Strike 1 MS. Strike 1.

[#15]

@yoelh
our production application is impacted as well, but different
Our desktop application uses a deeplink to redirect back to the desktop app at the end of the login. Only on windows, we experience that nor Edge, Chrome or Firefox want to open a >= 2048 character URL. On mac, no issue.

Does anyone experience this as well?

None of our customers can login any more

[#16]

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.

[#17]

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?

[#18]

@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

[#19]

If you are running Nginx as reverse proxy, this is the fix:

proxy_buffer_size                       16k;
proxy_buffers                           4 16k;

@yoelh

[#20]

@Florian Wachs If I might ask, what IIS server configuration mitigated this issue for you?