How to rotate web app environment variables?

Question

Looking to rotate the environment variables for my Web App for increased security. Unsure how to rotate the following default variables: WEBSITE_AUTH_SIGNING_KEY, WEBSITE_AUTH_ENCRYPTION_KEY, and WEBSITE_AUTH_ENABLED.

Default in this context means these variables were automatically included in the web app upon creation even with no code deployment.

Do I even need these variables in my app? How are they being used?

This question is being posted as part of an internal effort at Microsoft to share emerging content with the community. A Microsoft employee will be following up with an answer shortly. If you have feedback regarding this issue, we encourage the community to start a discussion in the comments.

Answer 1

The app settings WEBSITE_AUTH_SIGNING_KEY, WEBSITE_AUTH_ENCRYPTION_KEY and WEBSITE_AUTH_ENABLED are used by Easy Auth (the integrated Azure App Service Authentication / Authorization feature) to sign authentication session cookies and X-ZUMO-AUTH tokens (for customers who use those). These are usually added in the environment variable automatically when the app is created. A JWT-based token is submitted either as a cookie or as the X-ZUMO-AUTH header. The WEBSITE_AUTH_ENABLED will be true if the Authentication system is loaded and if set to True, decodes the X-ZUMO-AUTH header to see if the user is valid. If the user is valid, then a HTTP GET of {issuer}/.auth/me with the X-ZUMO-AUTH header is passed through to get a JSON blob with the claims, whereas if the token is expired or non-existent, then the user is not authenticated. In addition, these are also used in some operations / scenarios that MS can run internally.

• Is it possible to change these settings?

You can specify your own values in App Settings, but the signing key needs to be a SHA-256 hashed string. You could rotate them as you see fit. The side effect of rotating this value is that existing login sessions will be broken, and users will be required to re-login into the app. The current configuration surface area does not allow you to have more than one signing key value, so the recommendation is to do rotation during a period of low website traffic. In some scenarios, it may render session cookies previously created invalid which, I assume, the module reading cookie would handle it as if there was no cookie in the first place.

• What are the risks of having them compromised?

It depends for what they are being used. In the case of Easy Auth, compromised keys could allow an attacker to create fake authentication cookies to impersonate another user.

• If we change these keys, would we have to also change something on the Azure AD side? Will Azure AD know how to decode it?

No, these keys are never used for any interactions with Azure AD or any other identity provider. They are only used for internal functions, like signing cookies and internal communication within the app and the underlying App Service platform.
The key used to authenticate with Azure AD is typically represented by the WEBSITE_AUTH_CLIENT_SECRET environment variable. This environment variable is not directly settable by customers. Rather, it is derived from ARM settings.

Helpful Blog Post: Azure App Service Authentication in an ASP.NET Core Application – Adrian Hall (wordpress.com)