Preserve URL fragment in App Service with built-in Authentication

Peter Jakubis 0

Hello,

I have setup App Service with built-in Authentication using Microsoft as identity provider following the guides in https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service?tabs=workforce-configuration.

Authentication itself is working as expected.

I need to preserve URI fragment after the login flow is finished. I have added WEBSITE_AUTH_PRESERVE_URL_FRAGMENT=true into application settings as documented in https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-customize-sign-in-out#preserve-url-fragments, but the URI fragment is still stripped.

Do I need to configure something else?

Bhargavi Naragani 420 Reputation points Microsoft Vendor

2025-01-31T08:54:25.69+00:00
Hi @Peter Jakubis,
Welcome to the Microsoft Q&A Platform!
It seems like you have set up App Service with built-in Authentication using Microsoft as the identity provider and that authentication is working correctly. However, despite setting WEBSITE_AUTH_PRESERVE_URL_FRAGMENT=true, the URI fragment is still being stripped after login.

Ensure WEBSITE_AUTH_PRESERVE_URL_FRAGMENT=true is correctly configured in your App Service Application Settings (check for typos or case sensitivity), restart the App Service after adding/modifying this setting.

If your app is a Single-Page Application (SPA) (e.g., React, Angular, Vue), the fragment is handled client-side. Add logic to capture and retain the fragment after authentication:
For Example (React):
useEffect(() => { const fragment = window.location.hash; if (fragment) { // Store or use the fragment (e.g., routing, state management) console.log("Fragment:", fragment); } }, []);

In the Azure Portal, navigate to your AppService>Authentication, confirm you’re using the V2 configuration (the newer authentication experience). If not, reconfigure the Microsoft identity provider under the updated interface.

Use a simple test URL, after logging in, check if the fragment (#test-fragment) persists in the URL.

Open your browser’s developer tools (F12) and monitor network requests during login, verify the redirect_uri includes the fragment (it may appear as a query parameter like state=...&fragment=...).

Disable any custom redirect rules or code that might interfere with the authentication flow, review the App Service logs (Diagnose and solve problems > Application Logs) for errors.

If fragments still fail, use query parameters (e.g., ?param=value) instead of fragments, as they are server-supported and preserved by default.

If you have any further concerns or queries, please feel free to reach out to us.
Bhargavi Naragani 420 Reputation points Microsoft Vendor

2025-02-03T03:53:53.88+00:00

Hi @Peter Jakubis,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Peter Jakubis 0 Reputation points

2025-02-03T10:37:49.6966667+00:00
Hi @Bhargavi Naragani ,

Thanks for your input.

I have checked that already several times and also tried to restart the app several times. It didn't help.

It's not SPA

This is a new App Service. As far as I know you cannot setup V1 in the Azure Portal anymore. The Portal doesn't say it's V2, but I am pretty sure it is.

No it doesn't after the login/redirect flow. If I login and paste URL with fragment again it works as expected.

there is no fragment or any other field in the redirect URI that contains the fragment

No custom redirect rules or code.

At this time I cannot modify the App's code itself to switch to parameters.
Bhargavi Naragani 420 Reputation points Microsoft Vendor

2025-02-04T08:01:52.73+00:00
Hi @Peter Jakubis,
Thank you for confirming and for trying out the suggestions. You have checked several times and restarted the app without success, and since it's a new App Service probably V2, let's look at other probable causes.

Since URI fragments are never sent to the server, your client-side code must explicitly preserve the fragment during the login flow.
Add this JavaScript to your app:

// Save the fragment before redirecting to login if (window.location.hash && !isAuthenticated()) { // Replace with your auth check sessionStorage.setItem('preLoginHash', window.location.hash); window.location.href = '/login'; // Trigger EasyAuth redirect } // After login, restore the fragment if (sessionStorage.getItem('preLoginHash')) { window.location.hash = sessionStorage.getItem('preLoginHash'); sessionStorage.removeItem('preLoginHash'); }

Ensure your Azure AD (or other identity provider) allows the redirect URI with fragments. While fragments aren’t sent to the server, the client-side logic must still handle them.

Use browser devtools to check network requests and ensure no server-side redirects strip the fragment.

Test in an incognito window to rule out caching issues.

Key Points:

App Service authentication (EasyAuth) sometimes needs the application to handle the fragment correctly. The fragment (after the #) is never sent to the server because it's client-side. So, after authentication, the server can't know what the fragment was unless the client stores it and appends it back. The Azure documentation mentions that enabling this setting helps, but maybe the client-side code isn't handling it.

Might need to modify client-side code to capture the fragment before redirecting to the login page. For example, using JavaScript to store the fragment in sessionStorage or localStorage before redirecting, then retrieving it after coming back from the login flow. Let me outline that process: when the user tries to access a page with a fragment, the client should detect they're not authenticated, save the fragment, redirect to login, and after login, check if there's a saved fragment and append it.

possibility is there; the authentication flow isn't returning to the correct URL with the fragment. The redirect URI after login might be missing the fragment. Since the server can't handle fragments directly, the client needs to manage this. The user should ensure that their post-login redirect URL includes logic to reattach any stored fragment.

App Service needs to be restarted after adding the setting. Sometimes configuration changes require a restart to take effect. check if app got restarted after setting the environment variable.

There might be a conflict with other redirect URLs or settings in the authentication configuration. The allowed external redirect URLs should include the domain and any parameters necessary, but since fragments aren't sent to the server, this might not be the issue. Still, it's worth checking if any other settings are overriding the fragment preservation.

Hope the above provided information help in better understanding and help you resolve the issue, if you have any further concerns or queries, please feel free to reach out to us.
If the answer is helpful, Kindly Upvote it
Bhargavi Naragani 420 Reputation points Microsoft Vendor

2025-02-05T09:44:20.79+00:00

Hi @Peter Jakubis,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Bhargavi Naragani 420 Reputation points Microsoft Vendor

2025-02-06T11:41:24.09+00:00

Hi @Peter Jakubis,
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Share via

Preserve URL fragment in App Service with built-in Authentication

Your answer