Bypass Azure B2C redirect uri limit

Question

Background

When configuring authentication using Azure B2C, you register your app within Azure and specify return Uri's that Azure are allowed to redirect back to. These redirect Uri's have a max limit of 256 uri's . My client that I implement this for have multiple subdomains and top domains that are directed to the same site with different cultures (using Optimizely CMS). This means that they will break the limit of 256 Uri's if all of these are registered in the app. Also, it would be a tedious job to configure every single Uri in the app registration. Thus, I am trying to figure out the best approach to solve this without breaking best practices.

Expectation

I am hoping to find a solution that would allow me to only have to register one or a hand full redirect Uri's in Azure app registration, but still being able to use multiple different subdomains and top domains to initiate an authentication flow.

Approaches

State parameter Using the state parameter you are able to pass custom data throughout the entire authentication flow. In this way you can pass your own redirect Uri. However, this seems to only works for paths and subdomains, but not with top domains. If I pass a different top domain then the one I am initiating the authentication, I end up in a redirect loop. My guess is that it is due to the cookie not being able to be set since it is cross domain.

Wild card Uri's By defining Uri's using wild cards it is possible to minimize the amount of domains registered. But this approach is not recommended due to security implications.

Multiple app registrations One approach could be to configure the OpenIdConnect solution to handle multiple app registration. Thus, that a group of Uri's are connected to one app registration, and another group to another app. And depending of the request url the correct app registration is used to initiate an authentication request. This sounds to me to as quite good solution, but it does not minimize the workload needed to add all redirect Uri's and maintaining them.

Wrap the authentication flow in a custom solution In this approach only one specific top domain (domain A) would be used to initiate an authentication towards Azure B2C. A user that want to logon from domain B would click a login button, the button redirects the user to domain A where the authentication is initiated towards Azure B2C. When the user is authenticated the user is redirected back to domain A where a token (or similar) is created and then sent back to domain B. When the token reaches domain B this is saved in the session and the user is then considered authenticated. I don't like this approach. Feels like the entire purpose of Azure B2C is lost if this approach is used, and also this would add more complexity and attack vectors.

Questions

Is there any of these approaches that you would recommend? Is there any other approaches I've missed that might work?

Answer 1

As a former Episerver/Optimizely developer I have to say that I would reconsider your architectural approach if you are surpassing 256 domains/subdomains. Are you using a different subdomain for each language version?

Anyhow, if you insist on your approach, I would recommend registering each top level domain as a single Redirect Uri and then handling the subdomain/path in the state. That could mean that authentication is handled under www.domain.com and then using state you are redirected back to en.domain.com or de.domain.com . This will probably require implementing a custom controller that handles the authentication flow, state and setting cookie domains correctly.