Re: [OAUTH-WG] OAuth 2.0 Threat Model and Security Considerations
Keep in mind that the first priority is still the OAuth 2.0 main spec, so let's wrap that up. Â We're aiming for working-group last call on that within the month. Does within the month mean by the end of June? :) Yes; we're very aggressive, here in OAuth land. On the other hand, maybe the end of July would do. Barry ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 16 comment
+1 for (1) As pointed out in another posting (http://www.ietf.org/mail-archive/web/oauth/current/msg06723.html), I think we have consensus on the patterns for native app implementation. So in my opinion, we need to adjust the client authentication part to fit. In my opinion, the authz server cannot prevent a client from using another clients id, even pre-registering a redirect_uri won't help. But this only means, the authz server cannot provide the user with trustworthy data regarding the app. In this case it is the task of the user and the platform the app is running on to detect malicious clients (maleware, viruses). regards, Torsten. -Ursprüngliche Nachricht- Von: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] Gesendet: Dienstag, 28. Juni 2011 12:26 An: Shane B Weeden Cc: oauth@ietf.org; oauth-boun...@ietf.org Betreff: Re: [OAUTH-WG] Draft 16 comment The question below remains unanswered in relation to native apps being able to use grant type auth code to utilize refresh tokens. Which of these is the best option 1) Change oauth spec so client credentials are optional when requesting access token for grant type 'authorization_code' and for refresh token requests 2) Edit section 9 on security considerations to remove any references to native apps using auth code The difficulty with option 1 is how do you then prevent attackers using a legitimate client identifier. If we change the spec to say the client SHOULD pre-register it's redirect-uri, would that suffice? Regards Mark oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22: From: Shane B Weeden swee...@au1.ibm.com To: oauth@ietf.org Date: 23/05/2011 06:26 Subject: [OAUTH-WG] Draft 16 comment Sent by: oauth-boun...@ietf.org First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling instance secret for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ 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
[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
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
[OAUTH-WG] Native Application Text
9. Native Applications A native application is a client which is installed and executes on the end-user's device (i.e. desktop application, native mobile application, etc.). Native applications may require special consideration related to security, platform capabilities, and overall end-user experience. The following are examples of how native applications may utilize OAuth: o Initiate an Authorization Request using an external user-agent: The native application can capture the response from the authorization server using a variety of techniques such as the use of the various methods for redirection including a URI identifying a custom URI scheme (registered with the operating system to invoke the native application as handler), manual copy-and-paste, running a local webserver, browser plug-ins, or by providing a redirection URI identifying a server-hosted resource under the native application's control, which in turn makes the response available to the native application. o Initiate an Authorization Request using an embedded user-agent: The native application obtains the response by directly communicating with the embedded user-agent. Techniques include monitoring state changes emitted during URL loading, monitoring http headers, accessing the user-agent's cookie jar, etc. When choosing between launching an external user-agent and an embedded user-agent, native application developers should consider the following: o External user-agents may improve completion rate as the end-user may already have an active session with the authorization server removing the need to re-authenticate, and provide a familiar user-agent user experience and functionality. The end-user may also rely on extensions or add-ons to assist with authentication (e.g. password managers or 2-factor device reader). o Embedded user-agents may offer an improved end-user flow, as they remove the need to switch context and open new windows. o Embedded user-agents pose a security challenge because end-users are authenticating in an unidentified window without access to the visual protections found on by many of the external user-agents. Embedded user-agents educate end-user to trust unidentified requests for authentication (making phishing attacks easier to execute). When choosing between implicit and authorization code grant types, the following should be considered: o Native applications that use the authorization code grant type flow SHOULD do so without using client password credentials, due to the native application's inability to keep those credentials secure. o When using the implicit grant type flow a refresh token is not returned ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
