Subject: [OAUTH-WG] Resource Owner Password Credentials question/feedback

From: George Fletcher <[email-masked]>
Date: Tue, 28 Jun 2011 11:47:17 -0400

I'm working on spec'ing out a use of the Resource Owner Password 
Credentials flow and in trying to map out possible error cases, realized 
that there is no good error for the case that the resource owner's 
password credentials are invalid. Section 4.3 of draft 16 references 
section 5.2 for errors. The list of available errors in section 5.2 are...

    error
          REQUIRED.  A single error code from the following:
          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.
          invalid_client
                Client authentication failed (e.g. unknown client, no
                client credentials included, multiple client credentials
                included, or unsupported credentials type).  The
                authorization server MAY return an HTTP 401
                (Unauthorized) status code to indicate which HTTP
                authentication schemes are supported.  If the client
                attempted to authenticate via the "Authorization" request
                header field, the authorization server MUST respond with
                an HTTP 401 (Unauthorized) status code, and include the
                "WWW-Authenticate" response header field matching the
                authentication scheme used by the client.
          invalid_grant
                The provided authorization grant is invalid, expired,
                revoked, does not match the redirection URI used in the
                authorization request, or was issued to another client.
          unauthorized_client
                The authenticated client is not authorized to use this
                authorization grant type.
          unsupported_grant_type
                The authorization grant type is not supported by the
                authorization server.
          invalid_scope
                The requested scope is invalid, unknown, malformed, or
                exceeds the scope granted by the resource owner.

I'm wondering if others have chosen one of these values to represent the 
"invalid_credentials" use case.

Thanks,
George

---

From: Brian Campbell <[email-masked]>
Date: Tue, 28 Jun 2011 10:05:04 -0600

invalid_grant seems like the appropriate error as the username and
password are the grant in the context of the Resource Owner Password
Credentials flow/grant type.

On Tue, Jun 28, 2011 at 9:47 AM, George Fletcher <[email-masked]> wrote:
>
> I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for errors. The list of available errors in section 5.2 are...
>
>    error
> I'm wondering if others have chosen one of these values to represent the "invalid_credentials" use case.
>
> Thanks,
> George
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 28 Jun 2011 09:40:22 -0700

Yep. Invalid grant is the right error code.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Campbell
> Sent: Tuesday, June 28, 2011 9:05 AM
> To: George Fletcher
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Resource Owner Password Credentials
> question/feedback
> 
> Credentials flow and in trying to map out possible error cases, realized that
> there is no good error for the case that the resource owner's password
> credentials are invalid. Section 4.3 of draft 16 references section 5.2 for
> errors. The list of available errors in section 5.2 are...
> >
> >    error

---

From: Marcus Better <[email-masked]>
Date: Wed, 29 Jun 2011 11:58:21 +0200

> Credentials flow/grant type.

What should the HTTP status code be? The spec seems to indicate 400, but
I would think 401 would be appropriate?

Cheers,

Marcus

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Wed, 29 Jun 2011 14:08:13 +0200

> -----Ursprüngliche Nachricht-----
> Von: Marcus Better [mailto:[email-masked]]
> Gesendet: Mittwoch, 29. Juni 2011 11:58
> An: [email-masked]
> Betreff: Re: [OAUTH-WG] Resource Owner Password Credentials
> question/feedback
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

401 would be the correct status code if OAuth would use HTTP authentication for the authentication of the resource owner. But it doesn't. Instead HTTP authentication (BASIC) is used to authenticate the OAuth client whereas the resource owner's credentials are passed via request parameters.

regards,
Torsten.

> 
> Cheers,
> 
> Marcus
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk4K9zkACgkQXjXn6TzcAQmI7gCg8nKkTbb2rKFAXTEMm6WMaPL0
> o3EAoKYHWKhCmqcFTZHDCcGpw65Leukz
> =ocuC
> -----END PGP SIGNATURE-----

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 30 Jun 2011 10:09:39 +0200

No exactly the topic but also related to this grant type

There is currently no parameter the client could use to explicitly request a refresh token. So server-policies based on user, client and scope are the only mean to decide whether a refresh token is issued or not. I consider this  to limited as there might be the desire this control this per authorization process, i.e. I client could ask the user whether he/she wants to "stay connected" or "stay logged in". A parameter to pass this information to the authz server would be useful.

regards,
Torsten.

Von: George Fletcher [mailto:[email-masked]]
Gesendet: Dienstag, 28. Juni 2011 17:47
An: [email-masked]
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

   error

         invalid_request

               otherwise malformed.

         invalid_client

         invalid_grant

         unauthorized_client

         unsupported_grant_type

               authorization server.

         invalid_scope

Thanks,
George

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 30 Jun 2011 01:47:55 -0700

Issuing a refresh token is more a function of the access grant duration than anything else. The client can always throw away tokens when it is done of if the user doesn't want to "stay connected", but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; [email-masked]
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback

regards,
Torsten.

Von: George Fletcher [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Gesendet: Dienstag, 28. Juni 2011 17:47
An: [email-masked]<mailto:[email-masked]>
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

   error

         invalid_request

               otherwise malformed.

         invalid_client

         invalid_grant

         unauthorized_client

         unsupported_grant_type

               authorization server.

         invalid_scope

Thanks,
George

---

From: "Lodderstedt, Torsten" <[email-masked]>
Date: Thu, 30 Jun 2011 15:38:25 +0200

>Issuing a refresh token is more a function of the access grant duration than anything else.

Agreed. How shall the user influence this duration? There is no direct interaction between authz server and end-user.

>The client can always throw away tokens when it is done of if the user doesn't want to "stay connected", but issuing long term credentials is not >really something the client asks but the server decides (based on user approval and policy).

This is a waste of resources. Moreover, how do you explain the end-user if a long-term authorization shows up in his service providers account management screen for a certain client he never explicitly authorized for long-term access?

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:[email-masked]]
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; [email-masked]
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback

EHL

regards,
Torsten.

   error

         invalid_request

               otherwise malformed.

         invalid_client

         invalid_grant

         unauthorized_client

         unsupported_grant_type

               authorization server.

         invalid_scope

Thanks,
George

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 30 Jun 2011 09:39:30 -0700

This debate has been going on for 3 years. In OAuth 1.0 it was called token attributes. Someone just need to write a proposal. Last time I tried, no one wanted to implement any such mechanism.

EHL

From: Lodderstedt, Torsten [mailto:[email-masked]]
Sent: Thursday, June 30, 2011 6:38 AM
To: Eran Hammer-Lahav; George Fletcher; [email-masked]
Subject: AW: [OAUTH-WG] Resource Owner Password Credentials question/feedback

regards,
Torsten.

Von: Eran Hammer-Lahav [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; [email-masked]<mailto:[email-masked]>
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback

regards,
Torsten.

   error

         invalid_request

               otherwise malformed.

         invalid_client

         invalid_grant

         unauthorized_client

         unsupported_grant_type

               authorization server.

         invalid_scope

Thanks,
George