Resource Owner Password Credentials grant and authorization

[Andrew Savinykh]

Hello all,

According to Oauth 2 spec in the section for Resource Owner Password
Credentials Grant:

> 4.3.1. Authorization Request and Response The method through which the client obtains the resource owner credentials is beyond the scope of
> this specification. The client MUST discard the credentials once an
> access token has been obtained.

Also:

> 4.3.3. Access Token Response If the access token request is valid and authorized, the authorization server issues an access token

I read the above such as the only authorization that is required for
obtaining the access token is username and password. However in the
master branch of DotNetOpenAuth as of the moment of writing an
additional authorization check is performed (in
`MessageValidationBindingElement.ProcessIncomingMessage`):

// Make sure the authorization this token represents hasn't
already been revoked.
if (!
this.AuthorizationServer.IsAuthorizationValid(authCarrier.AuthorizationDescription))
{
Logger.OAuth.Error("Rejecting access token request because the
IAuthorizationServerHost.IsAuthorizationValid method returned
false.");
throw new TokenEndpointProtocolException(accessTokenRequest,
Protocol.AccessTokenRequestErrorCodes.InvalidGrant);
}

Note that this is *in addition* to the authorization by user
credentials. To me it looks like it is not is the spirit of the spec.
In addition to supplying resource owner credentials as described in
section 4.3.1 of the spec (above) DotNetOpenAuth also requires a
client to somehow create the authorization record into the database.
How is this envisaged to be done?

Now I understand that looking in the master branch tip shows work-in-
progress i.e. unfinished code. I'm wondering what the plan is here and
how this is going to function. Could you please explain?

Thank you in advance,
Andrew Savinykh

[Andrew Arnott]

Hi Andrew,

Thanks for your feedback.  We do need to do some more work on the library around resource owner password grant types, both for authenticating and non-authenticating clients.  I've actually double checked the relevant sections of the spec with the working group behind the spec and it is very much in the spirit of the spec for the authorization server to apply additional checks beyond just a matching password before issuing tokens.  Here are a couple reasons:

Obtaining an access token and/or refresh token in exchange for user credentials is actually an elevation of privilege.  How can you have more power than a password would give you?  Well, with a token you can outlive a password.  If the user authorizes an app by sharing their password with it, and later realizes that was a mistake and changes their password to revoke access, from the user's perspective that would seem sufficient.  Yet with a refresh token a password change doesn't (necessarily) invalidate the token.  So the app still has permission to access user data.  

Another concern is simply brute force password attacks.  After several failed attempts, even a correct password guess may be rejected due to an account lockout.  But this may be scoped to specific clients.  For example, one client that is attempting a brute force attack may be blocked while a trusted client still may obtain authorization.  

These are just a couple reasons why an authorization server may apply additional checks prior to issuing tokens.  However as I said, more work in this area is warranted so that the authorization server can make informed decisions as to whether to issue tokens for an incoming request. The client, for example, needn't create an authorization record before following the standard oauth2 flow.  The flow is what is supposed to create that record automatically.  Watch for more in the near future.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Andrew Savinykh]

Andrew,

thank you this all makes sense.

Regards,
Andrew Savinykh

On May 5, 3:52 am, Andrew Arnott <andrewarn...@gmail.com> wrote:
> Hi Andrew,
>
> Thanks for your feedback.  We do need to do some more work on the library
> around resource owner password grant types, both for authenticating and
> non-authenticating clients.  I've actually double checked the relevant
> sections of the spec with the working group behind the spec and it is very
> much in the spirit of the spec for the authorization server to apply
> additional checks beyond just a matching password before issuing tokens.
>  Here are a couple reasons:
>
> Obtaining an access token and/or refresh token in exchange for user

> credentials is actually an *elevation* of privilege.  How can you have more
> power than a password would give you?  Well, with a token you can *outlive* a

> > To post to this group, send email to dotnet...@googlegroups.com<javascript:;>
> > .

> > To unsubscribe from this group, send email to

> > dotnetopenid...@googlegroups.com <javascript:;>.