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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, June 30, 2011 1:10 AM To: George Fletcher; oauth@ietf.org 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:gffle...@aol.com]<mailto:[mailto:gffle...@aol.com]> Gesendet: Dienstag, 28. Juni 2011 17:47 An: oauth@ietf.org<mailto:oauth@ietf.org> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
