I’ve had this scenario come up a few times now when working through various federation scenarios. These cases always involve using Facebook as an oAuth source for login, or Azure’s AppFabric ACS as a federated identity provider. The common behavior is that you are doing something either interactively through the browser or programmatically by making a POST to ACS. In either case, you get an error in the response, but the error is generally nondescript. For example, when using Facebook’s oAuth feature you get redirected to their site to login, you enter your credentials, and then you get redirected back to your application. When there is a problem though, in most cases the browser will just say you got a 400 response and the server encountered an error. That’s it. Same thing when programmatically posting to ACS – when there’s a problem you will often get a 400 type response back that often says “page not found” or something similar. How does that help you? It doesn’t!
Sadly, what I’ve discovered is the best thing to do when you see these pages is to use Fiddler (www.fiddler2.com). You will find signifcantly more details in the Fiddler response then the browser will ever show you. For example, with one of the ACS issues I saw in Fiddler that the response included details that said the POST message was incorrectly formatted. Ah, yeah, that’s a lot more useful than “page not found’, which doesn’t make sense to begin with. Or with Facebook, we discovered that in Fiddler the response actually said you’re redirecting back to an invalid or untrusted URI. Yeah, that’s a lot more useful than just giving me a 400 error and saying bad request.
So that’s the point – when you get to these apparent dead ends, fire up Fiddler and look at the details of the responses to try and find actual useful details about what has happened.