Azure / static-web-apps-cli

Azure Static Web Apps CLI ✨

Home Page:https://aka.ms/swa/cli-local-development

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Custom OpenIdConnectProviders is broken in 1.1.8

SirMrDexter opened this issue · comments

Before filing this issue, please ensure you're using the latest CLI by running swa --version and comparing to the latest version on npm.

Are you accessing the CLI from the default port :4280 ?

  • No, I am using a different port number (--port) and accessing the CLI from that port
  • Yes, I am accessing the CLI from port :4280

Make sure you are accessing the URL printed in the console when running swa start!

ℹ️ NOTE: Make sure to enable debug logs when running any swa commands using --verbose=silly

Describe the bug
When using custom identify providers with OpenID Connect, we should be able to login using the URL
/.auth/login/
Refer to docs: https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=openid-connect%2Cinvitations#configure-a-custom-identity-provider
But since 1.1.8, when you login using that URL you get a 404 response.
Instead when you change the login URL to /.auth/login/customOpenIdConnectProviders, then it works. This is contrary to how the URL works in the cloud.

To Reproduce
Steps to reproduce the behavior:

  1. Create a new swa project from scratch
  2. Add staticwebapp.config.json file with below content in it.
{
  "auth": {
    "rolesSource": "/api/my/roles",
    "identityProviders": {
      "customOpenIdConnectProviders": {
        "aadb2c": {
          "registration": {
            "clientIdSettingName": "AADB2C_PROVIDER_CLIENT_ID",
            "clientCredential": {
              "clientSecretSettingName": "AADB2C_PROVIDER_CLIENT_SECRET"
            },
            "openIdConnectConfiguration": {
              "wellKnownOpenIdConfiguration": "https://AADB2C_PROVIDER_ISSUER_URL/.well-known/openid-configuration"
            }
          },
          "login": {
            "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
            "scopes": [ "openid", "profile" ],
            "loginParameterNames": []
          }
        }
      }
    }
  }
}
  1. start the app using swa start
  2. Go to http://localhost:4280/.auth/login/aadb2c

Expected behavior
Should get the emulator login screen with the provider name as aadb2c

Screenshots
image
image

Desktop (please complete the following information):

  • OS: Windows
  • Version 10
  • Node Version 18
  • SWA Cli version: 1.1.8

I'm also getting this with aadb2c auth. Downgrading to 1.1.7 fixes it.

  "auth": {
    "identityProviders": {
      "customOpenIdConnectProviders": {
        "aadb2c": {
          "registration": {
            "clientIdSettingName": "AZURE_CLIENT_ID",
            "clientCredential": {
              "clientSecretSettingName": "AZURE_CLIENT_SECRET"
            },
            "openIdConnectConfiguration": {
              "wellKnownOpenIdConfiguration": "https://tenant.b2clogin.com/tenant.onmicrosoft.com/B2C_1_sign_in/v2.0/.well-known/openid-configuration"
            }
          },
          "login": {
            "nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
            "scopes": ["openid", "profile"],
            "loginParameterNames": []
          }
        }
      }
    }
  },

Edit to add:
A gotcha here is that you also need to change your registered callback URLs in your b2c configuration portal. if you change to aadbc like i did then your new callback uri should reflect that ie. https://mycoolapp.microsoftwhatever.net/.auth/login/aadbc/callback

Another gotcha is that it can take an arbitrary amount of time for Azure to update their redirect caches. This may lead one to an hour of work trying to figure out what they did wrong because aadb2c will report redirect_uri_mismatch errors even after you update your redirect configurations in the portal.

If you use User Flows then for some reason running the "Test User Flow" clears up this issue and your new callbacks will work. /shrug


I actually just ran in to this. This appears to be because of a difference in the expectations of the emulator's code and what the "documentation" suggest.

This issue is that these regex only parse for [a-z] and your custom provider is named "aadb2c" Which is what this documentation explicitly suggests.

if you change the name to something those regex can parse like "aadbc" it should work. You will need to change it everywhere in your staticwebapp.config.json.

ie:

{
  "auth": {
    "identityProviders": {
      "customOpenIdConnectProviders": {
        "aadbc": {
          "registration": {
            "clientIdSettingName": "AZURE_CLIENT_ID",
            "clientCredential": {
              "clientSecretSettingName": "AZURE_CLIENT_SECRET"
            },
            "openIdConnectConfiguration": {
              "wellKnownOpenIdConfiguration": "https://xxx.b2clogin.com/xxx.onmicrosoft.com/B2C_1_xxx/v2.0/.well-known/openid-configuration"
            }
          },
          "login": {
            "nameClaimType": "emails",
            "scopes": ["openid", "profile", "offline_access"],
            "loginParameterNames": []
          }
        }
      }
    }
  },
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/public/*"]
  },
  "routes": [
    {
      "route": "/sign-in",
      "redirect": "/.auth/login/aadbc"
    },
    {
      "route": "/sign-up",
      "redirect": "/.auth/login/aadbc"
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout?post_login_redirect_uri=sign-in"
    }
  ...
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aadbc?post_login_redirect_uri=.referrer"
    }
  }
}

@aoscodes I can confirm this as well. After the 1.1.8 update, it seems that numerical characters are no longer valid and only [a-z] works. I was able to "fix" the issue by changing the provider key in my staticwebapp.config.json from auth0 to authzero and then navigating to /.auth/login/authzero instead.

Downgrading to 1.1.7 is the workaround for now I suppose. StaticWebApps still appears to work in production, just not the emulator.