401 unauthorized for “/.auth/login/aad/callback” with external tenant

[SethvdAxe]

Describe the bug

We get a 401 unauthorised page after successfully(?) logging in with an account of an external tenant in our web app. We get it on the “/.auth/login/aad/callback” redirect. It does correctly work with ourselves as a tenant.

To Reproduce Steps to reproduce the behavior (see below for set-up that works):

1. The external organization registers an app registration with user.read() rights, id_tokens, creates a secret and sends us the application ID, tenant ID and secret value.
2. The external organization adds our domain and our domain + “/.auth/login/aad/callback” as web redirect URIs.
3. In our static web app azure configuration we set the AZURE_CLIENT_ID value and the AZURE_CLIENT_SECRET value to the one given by the external organization

4. "auth": {
   "identityProviders": {
    "azureActiveDirectory": {
      "registration": {
        "openIdIssuer": "https://login.microsoftonline.com/{EXTERNAL_ORGANIZATION_TENANT_ID}/v2.0",
        "clientIdSettingName": "AZURE_CLIENT_ID",
        "clientSecretSettingName": "AZURE_CLIENT_SECRET"
      }
    }
   }
   },

5. After a user (from the external organisation) logs in he gets redirected to the “/.auth/login/aad/callback” he sees a “401 Unauthorized” microsoft page.

Expected behavior

1. We have a static web app hosted on azure
2. We have implemented custom authentication
3. We want a single tenant to be able to log in
4. When we test this with ourselves as single tenant we set the staticwebapp.config.json as:

   "auth": {
   "identityProviders": {
    "azureActiveDirectory": {
      "registration": {
        "openIdIssuer": "https://login.microsoftonline.com/{OUR_TENANT_ID}/v2.0",
        "clientIdSettingName": "AZURE_CLIENT_ID",
        "clientSecretSettingName": "AZURE_CLIENT_SECRET"
      }
    }
   }
   },

5. We create an app subscription with id_tokens enabled and the microsoft graph user.read() rights enabled.
6. We create a secret in the app subscription and copy the secret VALUE and the app subscription APP ID
7. In the static web app configuration we define 2 variables named “AZURE_CLIENT_ID” and “AZURE_CLIENT_SECRET”, we give these the values of the secret and the app id.
8. We add our website name and our website name + “/.auth/login/aad/callback” as Web redirect URIs.
9. After doing this we can successfully log in on the front end, and this login is restricted to ourselves as a tenant.
10. When using '/.auth/me' authInfo.clientPrincipal we can verify that the user was correctly logged in

Screenshots

Device info (if applicable):

• All devices

Additional context Replicating the problem for our organisation (our own tenant and application id): We are able to replicate the problem in our organisation when in the static web app configuration we intentionally set a wrong AZURE_CLIENT_SECRET secret value. This had led us to double check and reset the secret value with the external organization but this did not help.

[3limin4t0r]

I personally encountered the 401 response when using https://login.microsoftonline.com/organizations/v2.0. Swapping organizations out for an explicit tenant guid worked. This didn't solve my issue because I need users from different tenants to be able to sign in. So I tried common instead, which works without producing a 401 callback response.

[LuKePicci]

According to https://learn.microsoft.com/en-us/entra/identity-platform/howto-convert-app-to-be-multi-tenant#update-your-code-to-handle-multiple-issuer-values and https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens#multi-tenant-applications it seems SWA should use special validation logic in case of multitenant. If common works, and organizations does not, may be they didn't implement organizations endpoint support.