We want to set up our own OAuth 2.0 authorization server based on the following roles:
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.
The OAuth 2.0 Password Grant Type is a way to get an access token given a username and password. It's typically used only by a service's own mobile apps and is not usually made available to third party developers. Update: The password grant type is prohibited in the latest OAuth 2.0 Security Best Current Practice.
The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.
Unfortunately, this grant type has been deprecated as well... Use Authorization Code Grant (with Proof Key for Code Exchange).
The Authorization Code Grant Type is probably the most common of the OAuth 2.0 grant types that you'll encounter. It is used by both web apps and native apps to get an access token after a user authorizes an app.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With