6
votes

We want to set up our own OAuth 2.0 authorization server based on the following roles:

  • Resource Server - An API built with ASP.NET Web API
  • Client - A web application built with ASP.NET MVC
  • Resource Owner - The end user

We plan to use the password grant type (Resource Owner Password Credentials Grant) such that the Resource Owner will submit their credentials to the Client, who will in turn make an Authorization Request. We want to authenticate the Client Request with Basic Authentication.

I'm struggling with how to set up an Authorization server using DNOA that supports this grant type. I've downloaded the Authorization Server sample project but this appears to be using token based grants (user authenticates directly with authorization server - in the sample, via OpenID).

When I try and make an Authorization request using fiddler I'm just redirected to the login page, so I'm assuming this sample doesn't support this grant type:

POST http://localhost:50172/oauth/authorize HTTP/1.1
User-Agent: Fiddler
Host: localhost:50172
Content-Length: 103

grant_type=password&client_id=sampleconsumer&client_secret=samplesecret&username=user&password=password

The same is true if I use basic authentication.

Any help would be appreciated. I've used DNOA with great success in the past to consume OAuth services, but am finding the documentation on setting up/configuring a server pretty sparse.

1
I'm wading through the same process at the moment and it's taking a loooooooog time to get this working. Some of the samples supplied with DNOA are plain wrong and won't work as coded. I'm currently trying to figure out how to authorise clients as well as users. I'm stumped at the moment as the clientidentifier is never supplied to the methods that appear to need it.Jammer
Jammer, I'd like to hear more about the "just plain wrong" samples. Can you email feedback to [email protected] please?Andrew Arnott

1 Answers

2
votes

It looks like you are sending the password grant to the authorization server's authorization endpoint which is wrong. Grants should go directly to the token endpoint, which must be at a URL that the authorization server does not require an authenticated request to access (i.e. won't cause ASP.NET to redirect to the login page).

That said, it's very unusual (and discouraged) for a web based client app to ask the user for a password to another web service. The authorization code flow is by far the preferred one for the scenario you sound like you're describing.