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

[Eran Hammer-Lahav <[e-mail]>]

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:[e-mail]]
Sent: Thursday, June 30, 2011 6:38 AM
To: Eran Hammer-Lahav; George Fletcher; [e-mail]
Subject: AW: [OAUTH-WG] Resource Owner Password Credentials question/feedback

>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:[e-mail]]<mailto:[mailto:[e-mail]]>
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; [e-mail]<mailto:[e-mail]>
Betreff: RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Lodderstedt, Torsten
Sent: Thursday, June 30, 2011 1:10 AM
To: George Fletcher; [e-mail]<mailto:[e-mail]>
Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback

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:[e-mail]]<mailto:[mailto:[e-mail]]>
Gesendet: Dienstag, 28. Juni 2011 17:47
An: [e-mail]<mailto:[e-mail]>
Betreff: [OAUTH-WG] Resource Owner Password Credentials question/feedback

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