400 Bad Request when using oAuth against ACSv2 in Production

Question

I'm using the following endpoint and get a 400 Bad Request 

https://sonamtest.accesscontrol.windows.net/v2/OAuth2-13

Headers are below

{X-AspNetMvc-Version: 2.0

x-ms-request-id: fdbdb901-30f2-4970-aba7-442bc3301d2a

Connection: Keep-Alive

Content-Length: 89

Cache-Control: private

Content-Type: application/json; charset=utf-8

Date: Sat, 09 Apr 2011 02:49:14 GMT

Set-Cookie: ASP.NET_SessionId=g3zoaqytfflk5x2bs0fcfqbu; path=/; HttpOnly

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

 

}

Answer 1

Hi Chris,

It should has returned some JSON content. The content might be:

{"error":"invalid_request","error_description":"ACS90007: Request method not allowed. "}

From The OAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-13:

invalid_request
 The request is missing a required parameter, includes an
 unsupported parameter or parameter value, repeats a
 parameter, includes multiple credentials, utilizes more
 than one mechanism for authenticating the client, or is
 otherwise malformed.

So my suggestion is to check the parameters and ensure they are correct.

Thanks,

Answer 2

Can someone confirm that the OAuth samples posted on acs.codeplex.com will work in production and in labs?  I'm unable to get any of them to work, nor the "ConfigureACSConsoleApplication".  

 

I've used ACS before, and have the MVC sample running correctly.  I've carefully gone through each step in the directions but can't get it to work.  I've re-downloaded and retried the process several times.  The fact that I get different responses in prod and labs indicate to me there may be something else going on.

Answer 3

The samples that are hosted on CodePlex will work against production ACS only, not Labs.  Codeplex also links to a Microsoft Connect WIF/OAuth sample, this has not yet been updated to the latest draft of OAuth and therefore will not work with PROD.

If you're having issues with any of the samples in the downloadable package from Codeplex, can you provide more details?  Specifically, which sample are you running and what behavior/errors you're seeing?

Answer 4

That explains it!  I've spent most my time with the out-of-date OAuth example that doesn't work anywhere (as it's too old).

 

I didn't spend much time with the certificate-authentication with OAuth. I didn't think many people would use it, so I didn't put much time into trying it out.   Question for you... Is that other certificate-based OAuth example likely to be  (or currently is) used by a large service provider?  Perhaps I don't see the benefit, or haven't fully though about its potential.

Answer 5

It's hard to speculate what customers might use what features or protocols, but one could imagine a service authenticating itself to another service using a ServiceIdentity backed by a certificate, over OAuth 2.

Answer 6

Turns out that there were multiple issues with getting the OAuth sample to work.  I'll post a summary here for everyone's benefit

* The HTTP proxy "Bluecoat" changed something in my HTTPS packet going to the ACS service.  This caused authentication failures.  See the following cases for more information

111041316631921

111041801268969

 

* In this thread I was using an older version of the OData sample.   This code has been updated here: https://connect.microsoft.com/site1168/Downloads

 

 

Answer 7

It would be great if you could post a summary as you mentioned. 

I am getting unexplained 400 Bad Request responses from the ACS OAuth 2 endpoint. And I am behind our corporate Bluecoat web proxy...