No idea where else to turn at this point. We're in the final stages of developing our app, which is hosted in a Linux-based NodeJS v12 Azure Web App.
Our app hooks up to Azure AD B2C to store and manage user accounts. AD B2C is configured entirely with Custom Policies.
When we try to change our account's password via B2C, we proceed with the password change successfully, but then B2C tries to redirect us back to our website, and it fails with a 431.
The Referer is ridiculously long, and looks something like this: https://%ADTenant%.b2clogin.com/%ADTenant%.onmicrosoft.com/%CustomPolicyName%/api/SelfAsserted/confirmed?csrf_token=%Token%&tk=StateProperties=%Token%&p=%CustomPolicyName%?diags=%ListOfEncodedClaimsAndControlInformation%
Encoded, the entire thing is roughly ~1,800-1,900 characters long. We also have about ~1,000-1,100 characters in our cookies, and the destination URL is ~1,300 characters long, for a total of ~4.1-4.3k characters.
If we reload the page the referer becomes empty so the call works fine.
Strangely enough, when in Incognito, the issue does not arise; the Referer becomes empty and it works fine.
At first we thought it was the NodeJS 8KB request header size maximum, but our request header is under that. And it works locally; it only breaks when the app is in an Azure Web App, making it harder to troubleshoot.
We even added WEBSITE_AUTH_DISABLE_IDENTITY_FLOW=true to our Web App: no luck
If anyone out there has an idea, that would be amazing, as we're running thin on ideas here :(
Thanks!
I guess you can try use –max-http-header-size arg for node.
Related
I have been testing a Blazor Server app (ASP.NET Core 6.0) locally for a while with no issues. It authenticates against Azure AD, and everything works fine.
I deployed it to an IIS 10 server on Windows Server 2019 (after installing Websockets, ASP.NET hosting runtime, etc.) and now I can't get past authentication, either locally on the server or remotely.
When I hit the URL, it immediately redirects to the Microsoft Login page, where I enter my username (email), then password, then 2FA challenge, then the yes/no stay logged in page, and then it appears to hang for a short while (although in the tab it is constantly switching between "Working" and "https://login.microsoft.com...") and then it either comes up with Bad Request - Request Too Long, or just "We can't sign you in".
If it's the Bad Request error, then the cookie store will be full of .AspNetCore.Correlation.xxx and .AspNetCore.OpenIdConnectNonce.xxx cookies, which is what makes the headers too long, and creates the bad request. If it's the "we can't sign you in" error, then clicking the three dots, and saying sign out and forget, resets things which will next time result in the Bad Request error.
Just to check that I hadn't done anything stupid, I created a new blank app, using the Blazor Server template, and deployed that in place of my app. Exactly the same thing happened. I could run it locally in VS, but after publishing to IIS, exactly the same Authentication errors.
Does anyone have any ideas or pointers?
OK, for anyone who finds this in the future... it was a simple fix - but there are no error messages which point to it until you look very deeply.
When I set up both my app, and the Blazor template app, I let the scaffolder set them up, and get a secret from the Azure API, which it placed into my local secret store.
When I published the app to IIS, the ClientSecret was not copied.
The quick fix was to simply put the client secret into the appsettings.json file at which point everything came good immediately. The longer fix is to use the server-based secret store.
Apparently the looping was caused by the client secret not being present. :(
I have a Java Web App which is integrated with Azure AD. Now when I run the app locally, everything works fine.
But When I deploy the WAR file to the Azure App Service, the authentication redirection seems to be going in an infinite loop.
The application is running in loop between login.microsoftonline.com and mysite.azurewebsites.net.
I have read in blog posts that this happens with OWIN cooke in .Net , but not sure if this is case with Java as well.
All the traffic is through HTTPS only, but still the issue exists.
Is there any setting in Azure Portal to overcome this ?
Owin middleware is only available for .NET, so yes, we cannot fault that.
The redirect would be triggering from the portion of your code that evaluates a condition like 401 Unauthorized and constructs an authentication Url and redirects the user to that.
I'd suggest you enable as much diagnostics as possible and look into logs to..
Azure AD is sending the tokens in response as expected and not an error
The code acceptig/parsing these tokens is working correctly
We're setting up SAML2 SSO using Azure AD, and we set the Reply URL incorrectly the first time. Now, I am unable to login with the original credentials we tested with as they are being redirected to the incorrect Reply URL. Any new user accounts work fine.
I'm unable to find any documentation saying how long this type of caching may take place, but I've cleared all client-side caches and am at a loss for what we could do without recreating the app (which we'd like to try to avoid).
We are developing an UWP app using ADAL authentication in Azure. We have configured our client in Azure Portal with the Redirect URI taken from the result of this method:
Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri()
It was working at the beginning, but now we've noticed that the URI generated by that method has changed. Therefore our login with ADAL does not worked anymore, stating that
The reply address 'ms-app://s-1-15-2-104.......' does not match the reply addresses configured for the application.
Of course, we added the new value of the URI to the client configuration, and it worked, but after a day or two it has changed again. I think this is not the right way to update the Azure configuration every couple of days.
How can we ensure that the result of GetCurrentApplicationCallbackUri stays unchanged?
The GetCurrentApplicationCallbackUri uses your app's SID to construct the URL. I'm not sure of the exact mechanics of it, but if you are still developed the app, especially in a team, the SID can change.
One way to ensure that it remains fixed, is to create the Application in the Windows Dashboard and associate the app with the Store:
From Visual Studio - right click on the Project and select Store->Associate app with the store.
You don't have to submit, but associating the app will update the package.appxmanifest with the real values from the Dashboard and they will persist across developers.
From documentation:
To support SSO, the online provider must allow you to register a redirect URI in the form ms-app://appSID, where appSID is the SID for your app. You can find your app's SID from the app developer page for your app, or by calling the GetCurrentApplicationCallbackUri method.
So, I thought I had this all working until I deployed to a new set of environments. I have a webapp that's authenticating just fine with multi-tenant WAAD users. But when I try to hit the webapp from an HttpClient after authenticating via AcquireTokenAsync I always get the login page as the result.
The only concrete thing I have to go in is the fact that the on-boarding process never seems to complete. The login prompt always asks me to give the WebApp and Native Client permissions.
I've triple checked client ids, tenants, app id urls, etc. Is there anything else to investigate? I hit this snag once before only for it to just start working :(
Edit #1: Webapp + api works just fine via the normal cookies, just seems to completely ignore the Bearer token I'm setting?
So it turns out I had set the Audience on the WindowsAzureActiveDirectoryBearer object incorrectly so the token was never valid...