1

I have an Angular SPA application that runs on 300+ of distributed servers using Azure AD for authentication. Each server is its own application instance with its own database, so they need to remain as separate websites.

The current Uris are:

https://myapp.server1.contoso.com/

https://myapp.server2.contoso.com/

https://myapp.server3.contoso.com/

etc.

how do I avoid the max redirect URI limit of 256?

Microsoft says to use a state parameter but this does not appear to work across subdomains. https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url

DeveloperSam
  • 11
  • 2
  • Do you really have redirect URI's larger than 256 chars? Can you post a sample URL? – Tore Nestenius Jul 11 '21 at 09:26
  • 1
    It’s not the URL character length that is us the issue, it’s the number of redirect Uris that can be added – DeveloperSam Jul 11 '21 at 12:50
  • Perhaps you could use some scripting/SDK and create one "instance" in AzureAd for each application instance? with automation that could be possible? I mean eventually, if you are successfull ,you might have 1000's of instance.... – Tore Nestenius Jul 11 '21 at 16:33

1 Answers1

1

Microsoft's idea with a state parameter should work, if you do the dispatching to the final target yourself.

Currently you try to register 300 URLs/Domains with Microsoft and have the flow just between AAD and your individual app. But you could change that, and register one "dispatcher" redirect URI that just redirects to the final location.

So instead of having just two parties involved (AAD, your RP) you would have three involved.

As pseudocode it could work like this, which is what Microsoft more or less tells you in the referenced docs:

  1. Start flow from your RP/App instance server1, but provide a redirect URI of "dispatcher.contoso.com/dispatch" and a state of " + server1".
  2. Now the auth flow runs its course and AAD redirects/posts the result to "dispatcher.contoso.com/dispatch".
  3. The dispatcher.contoso.com/dispatch then looks at the state value extracts the server1 and redirects the browser to "myapp.server1.contoso.com".

Maybe the dispatcher is just a load balancer that looks at some cookie scoped to the domain to pick the right target server (e.g. sticky cookies), maybe the dispatcher is some trivial code or rewrite rule. Your call.

I see no reason why this should not work for subdomains, what fails if you try?

schlenk
  • 7,002
  • 1
  • 25
  • 29
  • 1
    The flow itself makes sense, however azure AD tokens are stored in local storage using an absolute uri. This means when you redirect from azure to dispatcher.contoso.com/dispatch the token is stored in local storage then when you redirect to myapp.server1.contoso.com the token does not get transferred because the local storage was specific to dispatcher.contoso.com/dispatch – DeveloperSam Jul 15 '21 at 23:50
  • @DeveloperSam Did you ever come up with a solution or get this resolved? – Kurt W Jul 05 '23 at 14:54