Log into the Auth0 dashboard and navigate through to the Applications section of the portal:
Configure your Auth0 application
With your application created, it’s time to configure it. We’ll skip theQuick Startoptions, as we’re really doing something more custom. Instead, head toSettingsas we are going to need to provide the application with some redirect options for login/logout, so that SWA will know you’ve logged in and can unpack the basic user information.
For theSign-in redirect URIsyou will need to addhttps://<hostname>/.auth/login/auth0for theApplication Login URI,https://<hostname>/.auth/login/auth0/callbackforAllowed Callback URLsand forAllowed Logout URLsaddhttps://<hostname>/.auth/logout/auth0/callback. If you haven’t yet deployed to Azure, don’t worry about this step yet, we’ll do it once the SWA is created.
Quick note - theauth0value here is going to be how we name the provider in thestaticwebapp.config.json, so it can be anything you want, I just like to use the provider name so the config is easy to read.
Scroll down and clickSave Changes, and it’s time to finish off our SWA config file.
Completing our settings
With our Auth0 application setup, it’s time to complete our config file so it can use it. We’ll add a new configuration undercustomOpenIdConnectProvidersfor Auth0 and it’ll contain two core pieces of information, the information on how to register the OIDC provider and some login information on how to talk to the provider.
Insideregistration, we’ll add aclientIdSettingNamefield, which will point to an entry in theapp settingsthat the SWA has. Next, we’ll need aclientCredentialobject that hasclientSecretSettingNamethat is the entry for the OIDC client secret. Lastly, we’ll provide theopenIdConnectConfigurationwith awellKnownOpenIdConfigurationendpoint that ishttps://<your_auth0_domain>/.well-known//openid-configuration.
I useAUTH0_IDandAUTH0_SECRETas the names of the items I’ll be putting into app settings.
All this information will tell SWA how to issue a request against the right application in Auth0, but we still need to tell it how to make the request and handle the response. That’s what we use theloginconfig for. With theloginconfig, we provide anameClaimType, which is a fully-qualified path to the claim that we want SWA to use as theuserDetailsfield of the user info. Generally speaking, you’ll want this to behttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/name, but if there’s a custom field in your response claims you want to use, make sure you provide that. The other bit of config we need here is what scopes to request from Auth0. For SWA, you only needopenidandprofileas the scopes, unless you’re wanting to use anameClaimTypeother than standard.
With the config ready you can create the SWA in Azure and kick off a deployment (don’t forget to update the Auth0 app with the login/logout callbacks). When the resource is created in Azure, copy theClient IDandClient secretfrom Auth0 and create app settings in Azure using the names in your config and the values from Auth0.
Using the provider
Once the provider is registered in the config file, it is usable just like the other providers SWA offers, with the login being/.auth/login/<provider_name>, which in this case theprovider_nameisauth0. The user information will then be exposedas standardto both the web and API components.
I really like that with the GA of Static Web Apps we are now able to use custom OIDC providers with the platform. This makes it a lot easier to have controlled user access and integration with a more complex auth story when needed. Setting this up with Auth0 only takes a few lines of config.
You can check out a full code sampleon my GitHuband a live demohere(but I’m not giving you my Auth0 credentials :squinting_face_with_tongue:).