Multiple SWA can't be on the same domain due since root endpoint can't be changed

[dforslof]

Multiple SWA can't be on the same domain due since root endpoint can't be changed

TLDR: No possibility to serve application-x.azurestaticapps.net/.auth/ under application-x.azurestaticapps.net/\/.auth/ which leads to only one SWA being able to be served under one domain.

The easiest way to describe this is with an example:

Assume you have a domain example.com where we serve two applications: example.com/x and example.com/y. The proxy is done with an Application Gateway, so /x goes to application-x.azurestaticapps.net and /y goes to application-y.azurestaticapps.net, with header X-FORWARDED-FOR and X-ORIGINAL-HOST set by the proxy.

One solution is to serve the static files from a subdirectory x and y for each app. This would be fine, if you don't need authentication.

The authencation routes are served under application-x.azurestaticapps.net/.auth/*, and when behind the proxy this url becomes example.com/.auth which does not match any of our defined routes. Therefore the need to move the default /.auth files to /x/.auth becomes apparent.

To Reproduce Steps to reproduce the behavior:

1. Create a SWA where the root is on a different page than /, e.g. application-x.azurestaticapps.net/app-x/
2. Have a proxy for example.com that answers on the route example.com/app-x and forwards to application-x.azurestaticapps.net/app-x/ with rewritten host.
3. Try to login: example.com/app-x/login

{
  "trailingSlash": "auto",
  "routes": [
     {
      "route": "/app-x/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/app-x/profile*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "redirect": "/app-x/login",
      "statusCode": 302
    }
  }
}

Expected behavior Expected behavior is that more than one SWA can be created on the same domain, while supporting authentication.

[thomasgauvin]

Hi @dforslof, I understand your issue, though I'm not sure if allowing .auth at a different path would work, since the auth credentials for multiple SWAs would be found within the memory of the same site and would conflict. What do you expect the behavior to be for this case? The architecture you explain seems to indicate that for each path that represents a new SWA, a user would need to sign in again

[dforslof]

Yes you have understood the problem correctly.

Each application is published on its on route and requires the user to login again. However, today this login is done silently if the user is already logged in, and is handled by the OIDC protocol.

Out auth layer is today handled by an Apache proxy for each application, which publish its own auth endpoint (under the application route, so example.com/application_x/auth), since every application has its own OIDC CLIENT ID.

Is there no possible way to move the /.auth catalog from the root of the application to an arbitrary route on the application? I.e. from example.com/.auth to example.com/new_root/.auth

[dforslof]

I will leave this here as a better explanation. If static web apps is based on azurewebsites this should be very easy to implement: https://microsoft.github.io/AzureTipsAndTricks/blog/tip64.html

[jsheetzmt]

Also interested in something like this. We are using frontdoor with path routing and running into issues with ./auth/* always being referenced at the root

ourdomain.com/ -> routed to Azure Static Web App A (uses auth0) ourdomain.com/storybook/ -> routed to Azure Static Web App B hosting our storybook. (AAD auth)

Because the ./auth routes are always at the root, our traffic is getting redirected to Azure Static Web A after the user logs in. We want that traffic to go to App B

[OskarKlintrot]

I have the same setup and issue as @jsheetzmt just that we don't have anything under the root, all SWA is under different paths. My idea was to have one Azure Front Door and domain and then multiple SWA where people can deploy their docs to without having to bother with basically anything else than just setting up their SWA and they can't mess anything up for someone else (allowing them to experiment all they want). Using my Bicep template I can just add another path to an array and a few minutes later Azure Front Door and the new SWA is all setup and just waiting for the first deployment.

So I have this setup atm:

ourdomain.com/* => redirect to /AAA ourdomain.com/AAA => rewrite to my AAA-swa ourdomain.com/BBB => rewrite to my BBB-swa

Both AAA and BBB uses AAD (or Microsoft Entra, said the old man who yelled at clouds) but none can actually be accessed since all auth sooner or later ends up on ourdomain/.auth/*, resulting in an infinite loop or bad gateway, depending if I turn off the redirect or not. If I put one of the SWA directly at the root everything works fine (for that SWA).

[mvromer]

I have the exact same use case as @OskarKlintrot. I tried doing a similar setup last week and ran into the exact same issues regarding SWA auth. Ideally, we would let each of our internal teams publish their documentation to their own SWA. Then, we would make it accessible through a single Front Door domain that uses path-based routing rules to route a request to the appropriate doc site. The kicker is that we want to ensure only authenticated users can view the documentation. At that point, the aforementioned problems occur where auth flows end up at a fixed domain.com/.auth/ location, which won't work for any of the doc sites that are hosted (ideally) at domain.com/site-a/, domain.com/site-b/*, etc.

[OskarKlintrot]

Did I understand it correctly @dforslof that you're not trying to use any of the built in providers but rather your own OIDC server?

[OskarKlintrot]

@thomasgauvin is this a limitation in SWA or AAD?

[markalroberts]

Also interested - using App Gateway to rewrite "virtual apps" which alongside old-school IIS virtual directories under the same root domain - works fine until we need swa auth and then it breaks owing to rooted "/.auth" - sadly may need to use hosted Asp.net apps instead since this gives enough control to modify redirects/cookie paths etc. - would prefer to use swa+functions as this seems to be more Azure-friendly.