OAuth, ASP.NET Social Login Providers, and Debugging the Twitter API in Azure

Recently I migrated an instance of Social Opinion to a new subscription as part of the Microsoft for Start-ups program.

There were some configuration changes but nothing out of the ordinary.  The main changes being the URL and some database connection strings.

OAuth and out of the box .NET social login providers are used to perform he Twitter login but after the migration was complete, I found the login was broken and an http status code of 403 was being returned (Forbidden).

The application API keys and tokens weren’t changed meaning it couldn’t be those. The production instance was still operational using these keys and tokens, but this new dev instance still wouldn’t work.

Callback URLs

When authenticating with the Twitter API and OAuth, you need to specify one or more call-back URLs for Twitter to redirect to. These are set in the development console at developer.twitter.com for your respective Twitter Application.

I checked these and there mirrored the new web app URL instances for the new Azure subscription.

Remote Debugging

None of this was making any sense so I decided to do a remote debug of the new dev instance from Visual Studio.  As I connected to the new App Service in Azure, I hit the authentication code and sure enough, I received the 403 error but unfortunately the out-of-the box social providers didn’t give me detailed error information and explain why this error was being thrown.

Monitoring Requests Using Fiddler

By this point, given the production instance was still ok but this new dev instance was faulty, I fired up Fiddler and monitored the requests and traced the path of a successful login in the production instance.

By doing this, I could see the low-level http calls and the web application was hitting the following endpoints at the Twitter side:

• oauth/authenticate
• signin-twitter

After successful authentication, the production instance eventually redirects customers to their analytics landing page.  This wasn’t happening for the new dev instance.

Azure Application Insights

Application Insights is useful and contained more details.  Digging into the failures instance shows a further request is made to oauth/request_token:

The code and out-of-the-box social login code was not surfacing this error.  Being able to see requests were failing to oauth/request_token gave me more to work with.

Creating a Test Harness

To simulate a call to this endpoint I wrote a test harness in C# (without a social loging provider) and add some exception handling.  I also passed through the same API keys.

The 403 Status Code occurred like before with the Reason Forbidden.

This time I had more details information and could see the Error Code and Message from the Twitter API:  Code 69 and The given URL is considered malware.

This meant it could only be the new call-back URL and development site URL in Azure.

To confirm the theory, I tried random call-back URLs (and added these to developer.twitter.com in the portal).  I found that some worked, and some didn’t!

What Next

Now that I knew it was the callback URL, I thought there must be something at the Twitter end so contacted the DevRel Team.

Within 24 hours the issues were identified and resolved at the Twitter end. All authentication requests then started to behave as expected for new call-back URLs.

Summary

I’ve often found OAuth a pain. In this scenario there were so many different events and web requests being made back and forth between the new Azure instance to Twitter API.

The social login provider returned a generic forbidden message which made it harder to diagnose.  Luckily, digging into application insights gave me a little more detail and another avenue you try.

In the end, it turned out to be nothing at all related to the code but simply the allow-list needing updated at the Twitter end to include some extra Azure DNS wildcards.