Microsoft.Owin.Security.MicrosoftAccount Upgrade 3.0.1 to 4.0.0 Broke Microsoft Login

[wjchristenson2]

After 3.0.1 to 4.0.0 upgrade - we are no longer able to use Microsoft Account external logins. Others are fine (Twitter, Facebook, Google). We are aware of the issue going from 3.0.1 to 3.1.0 #112 and it appeared that 4.0.0 may have fixed it. It looks like the ExternalLoginCallback is being redirected to with error=access_denied. Our Microsoft app is setup correctly (same as what we were using for 3.0.1) and uses https. We are running ASP.NET MVC 5.2.6.0 .NET 4.5.2.

At first pass, I didn't see any issues and 4.0 has been out for awhile. Any changes required to get this back working?

[wjchristenson2]

About 1 month with no response. We are still unable to use Microsoft Account external logins after upgrading from 3.0.1 to 4.0.0. Any help would be appreciated. Thank you.

[Tratcher]

There aren't any known issues with the 4.0 MicrosoftAccounts provider. Can you share a Fiddler trace of the login flow?

[wjchristenson2]

@Tratcher I sent you an email to troubleshoot offline. We can circle back here once a resolution is found so others can benefit.

[Tratcher]

Oh I see. The most likely cause is an exception while processing the callback. That should show up in your app logs or under the debugger. https://github.com/aspnet/AspNetKatana/wiki/Debugging

Are you modifying the MA config in any way beyond supplying it the client id and secret?

[wjchristenson2]

No other config outside of clientId/clientSecret. I'll look into the debugging option and see what I can find.

app.UseMicrosoftAccountAuthentication( clientId: "00000000000000000", clientSecret: "xxxxx-xxxx-xxx-xxx-xx");

[wjchristenson2]

@Tratcher Here's what we get using the Microsoft.Owin.Diagnostics/Logging when I try and use the MS external login:

Microsoft.Owin.Security.MicrosoftAccount.MicrosoftAccountAuthenticationMiddleware Error: 0 : Authentication failed
System.Net.Http.HttpRequestException: Response status code does not indicate success: 400 (Bad Request).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at Microsoft.Owin.Security.MicrosoftAccount.MicrosoftAccountAuthenticationHandler.d__4.MoveNext()

Fiddler shows no 400/bad requests.

[Tratcher]

That 400 is on the request the server sends to MSA to exchange the code and get user information. You can capture it with System.Net logs:
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/how-to-configure-network-tracing

[wjchristenson2]

net-debug-results.txt

[Tratcher]

Nothing obviously wrong, MSA is just refusing your request. You could compare the trace with one from your 3.1 app to verify. Are you sure the client secret is correct? That's the most likely thing to fail at this stage.

The 400 response did have a 485 byte response with it that may explain the failure, but the contents aren't captured in the dump. Getting those might be trickier. Here are a few options.
A) Wireshark with TLS decryption enabled
B) Set MicrosoftAccountAuthenticationOptions.BackchannelHttpHandler with a HttpMessageHandler that logs the response body as it passes through.

[wjchristenson2]

@Tratcher I tried the wireshark option. After a few hours, I threw in the towel. I couldn't get the tool to decrypt the traffic due to Diffie-Hellman cipher fun. Got it all disabled in Chrome and then Chrome wouldn't let me navigate to the site due to "ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY". I downgraded Microsoft.Owin.Security.MicrosoftAccount back to 3.0.1 and it works perfectly. At this point, I need to move on to other tasks. Luckily we don't have many users using the external M$ sign-in feature, but they've been complaining for a month, so I'll need to downgrade and get things operational again.

[rxd2]

Similar experience, also not resolved
#203

[muratg]

@Tratcher related to us moving to V2 endpoints?

[fhtino]

I had the same issue: error=access_denied

I solved creating a completely new Application under the MS Application Registration Portal https://apps.dev.microsoft.com following the instruction here https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins

I noticed that theold, not working, applicationID was in the format 00000000XXXXXXX. The new applicationID is a guid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

[Tratcher]

@fhtino you're right, I've seen similar results elsewhere. Closing this pending any further reports.

[wjchristenson2]

I can confirm that the solution that @fhtino suggested worked. I deleted the old application and recreated a new one using 4.0.0 and it worked.

[alt22247]

@Tratcher I am having the exact error after upgrading from 3.1 to 4.0.1. This only happens with the old Live SDK applications. The new Converged applications work fine.

The new converged applications work if i do not explicitly specify the scope but the old Live SDK applications keeps giving me access denied with or without explicit scope.

Can you test this with a Live SDK applications (apps.dev.microsoft.com) and reopen this issue?

[Tratcher]

Is there some reason you're still using Live SDK applications? I was under the impression they were obsolete.