Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav: 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. we already did regards, Torsten. EHL *From:*Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] *Sent:* Thursday, June 30, 2011 6:38 AM *To:* Eran Hammer-Lahav; George Fletcher; oauth@ietf.org *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...@hueniverse.com] mailto:[mailto:e...@hueniverse.com] *Gesendet:* Donnerstag, 30. Juni 2011 10:48 *An:* Lodderstedt, Torsten; George Fletcher; oauth@ietf.org mailto:oauth@ietf.org *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:*oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] mailto:[mailto:oauth-boun...@ietf.org] *On Behalf Of *Lodderstedt, Torsten *Sent:* Thursday, June 30, 2011 1:10 AM *To:* George Fletcher; oauth@ietf.org mailto: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
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] Gesendet: Dienstag, 28. Juni 2011 17:47 An: 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
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: 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.orgmailto: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
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. 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...@hueniverse.com] Gesendet: Donnerstag, 30. Juni 2011 10:48 An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org 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: 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.orgmailto: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
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
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:t.lodderst...@telekom.de] Sent: Thursday, June 30, 2011 6:38 AM To: Eran Hammer-Lahav; George Fletcher; oauth@ietf.org 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...@hueniverse.com]mailto:[mailto:e...@hueniverse.com] Gesendet: Donnerstag, 30. Juni 2011 10:48 An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.orgmailto:oauth@ietf.org 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: oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]mailto:[mailto:oauth-boun...@ietf.org] On Behalf Of Lodderstedt, Torsten Sent: Thursday, June 30, 2011 1:10 AM To: George Fletcher; oauth@ietf.orgmailto: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.orgmailto: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
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-06-28 18:05, Brian Campbell wrote: 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. What should the HTTP status code be? The spec seems to indicate 400, but I would think 401 would be appropriate? 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- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
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 gffle...@aol.com 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 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback
Yep. Invalid grant is the right error code. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Tuesday, June 28, 2011 9:05 AM To: George Fletcher Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback 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 gffle...@aol.com 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 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
