Guten Tag!

Many greetings from Munich, Germany. In today’s newsletter we change the authentication for our Quarto project so that we can decide which users get to access our content. This will be similar to out GitHub authentication from last week.

But this time, we can restrict access to only a few selected persons (if we want that). And to do so, we’re going to use another service from Azure called “Azure Active Directory B2C”.

Create a new tenant

The first thing that you have to do is to create a new tenant for Azure AD B2C. To do so, you create a new resource.

And then, you select Azure AD B2C:

There you will have to specify the org name and domain name of your tenant. Just choose what you like (as long as Azure accepts the name.)

Switch tenant

Once you’ve created the tenant, you can switch to it via the settings icon at the top of the Azure portal.

Just remember that your Azure Static Web App now lives in a separate tenant. That’s why you’ll have to switch between tenants when you modify the app settings.

Register an application

In our new tenant, we can access the Azure AD B2C resource. There, we first have to register an application. This is like registering the OAuth app that we created last week on GitHub.

In the settings of that registration, you will have to enable all accounts to be allowed to “authenticate via user flows”. Also, make sure that the redirect URI of that application points to our app.

Watch out: The redirect URI now doesn’t contain .auth/login/github but instead contains .auth/login/aadb2c.

Client ID & Secret

Now that we have an OAuth app, we need to get client ID and client secret. This is exactly like what we did last week. The client ID is immediately displayed in the app page and the secret can be generated via the “Certificates & secrets” page.

There, you can generate a new secret.

Just make sure that you copy the secret as soon as you’ve created it. Otherwise, it will be lost as the secret will only be displayed once.

Create a new user flow

Remember how we had to enable “user flows”? You can think of this as the procedures that a user might want to go through. Common procedures are “sign in”, “sign up”, “reset password” or “edit profile”.

And that’s also what we need to set up inside of our AD B2C resource. We can do so via the “Policies” page.

There, we can create a new sign in flow so that users can sign in.

The rest is pretty straightforward: Pick a name and choose sign up methods.

If you want, you can also turn off multi-factor authentication and determine what information are transmitted when a user signs in.

Once you’re finished, you can see a new user flow in your Policies page. Notice that the name of the policy also includes “B2C_1_”. This little detail will become important in a sec.

Modify config file

Now that we have everything set up, we can change the auth settings of our web app. Once again, this only requires modifying the staticwebapp.config.json file. Luckily for us, the Azure docs also have the perfect auth code snippet for us:

Here, we need to replace

• <TENANT_NAME> with the domain name of our tenant, and

• <POLICY_NAME> with the user flow name that we have created earlier. Remember to use the name that includes “B2C_1_”.

Also, we can modify the requested scopes a bit. All in all, this should look something like this:

Finally, you should make sure that your redirect now moves users to .auth/login/aadb2c. Overall, the config file should look like this.

Once you’ve made these changes, make sure to rebuild your Quarto project and push the changes to our GH repo.

Set environment variables

Finally, the remaining thing that we have to do is set up environment variables inside of our app. You see, inside the auth snippet we now use AADB2C_PROVIDER_CLIENT_ID and AADB2C_PROVIDER_CLIENT_SECRET. These need to be set inside the environment variables page of our Azure Static Web App.

Redirect to login

Nice! We’ve set everything up so it’s time to test it. When you try to access the website of your Quarto project, you should be redirected to the following login screen.

While this is nice, it doesn’t matter what you put in there. The system won’t be able to find your user details.

Clearly, this happens because we’ve never defined a user base.

Add a user

We can add a user to our ADB2C resource via the Users page.

There, we just have to set up a new user.

The page just requires defining an e-mail address and a password. Once we have set that up we can use this mail and the password to sign up via our login page. This will successfully authenticate us and redirect us to our website.

And with that we have successfully changed the authentication once again 🥳 But this time we can customize who gets to sign in and who doesn’t.

As always, if you have any questions, or just want to reach out, feel free to contact me by replying to this mail or finding me on LinkedIn or on Bluesky.

See you next week,
Albert 👋

Enjoyed this newsletter? Here are other ways I can help you:

• My playlist on YouTube

• Free book: Yet Again - R + Data Science

• Free book: Beautiful tables with {gt}

• Blog posts