If a fragment was registered (or not) and if the authorization server policy require that any fragment provided in the callback matches a pre-reigstered value. Fragments, historically, were not very important and without any real security implications. However, with new browser-based applications, the fragment is used to maintain the application state and has the potential to be used to run code on the client by injecting it through a valid registered callback.
I'm ok with banning fragments completely, but what I much prefer and going to propose shortly is to require full, string-wise comparison of redirection URIs to their registered value. Clients can use the state parameter for any customization they need (and they can register multiple URIs). This seems like a much safer, and saner approach that doesn't take away any real functionality. EHL From: Shane Weeden <swee...@au1.ibm.com<mailto:swee...@au1.ibm.com>> Date: Sun, 3 Jul 2011 21:22:46 -0700 To: Eran Hammer-lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> Cc: Brian Eaton <bea...@google.com<mailto:bea...@google.com>>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>>, "oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>" <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> Subject: Re: [OAUTH-WG] draft 16 review notes >From 4.2.1 below: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the access token matches a redirect URI pre-registered by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. What does it mean for the authorization server to "verify the fragment component"? From: Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> To: Brian Eaton <bea...@google.com<mailto:bea...@google.com>>, "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Date: 04-07-11 01:25 PM Subject: Re: [OAUTH-WG] draft 16 review notes Sent by: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> From: Brian Eaton <bea...@google.com<mailto:bea...@google.com>> Date: Sun, 22 May 2011 20:38:53 –0700 1.4.1 Authorization Code maybe expand the section on important security benefits. “The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.” Can you explain? 4.2.1 Authorization Request Validation of the redirect_uri parameter is more important for the implicit grant type. Section 2.1.1 leaves registration of the redirect URI as “SHOULD”. It’s a “MUST” for the implicit flow. Suggested language: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the authorization code matches a redirect URI pre-registered by the client. The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. The authorization server MAY verify the query parameters as well. Changed it for now to: The authorization server validates the request to ensure all required parameters are present and valid. The authorization server MUST verify that the redirect URI to which it will redirect the access token matches a redirect URI pre-registered by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. I'm still not happy with this and want something stronger. 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passwords. How about: Since this access token request utilizes the resource owner's password, the authorization server MUST protect the endpoint against brute force attacks. Section 10. Security Considerations There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf Care to extract and edit for inclusion? Section 10.1 Client Authentication nit: “MUST NOT issue client passwords to installed apps” is a dead letter, it is not going to change standard industry practice in the slightest. The language from section 3 is more constructive. I’d suggest the following language for section 10.1 instead “The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.” That does conform with industry practice, so it’s more likely to be implemented. Do we have consensus for this change? Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for “immediate mode”, where authorization requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. Need proposed text. 10.3 Access Token Credentials “When using the implicit grant type, the access token credentials are transmitted in the URI fragment, which can expose the credentials to unauthorized parties.” That’s basically FUD. This should be made much more specific. It falls into the general category of security considerations for redirectors and clients... Need proposed text. 10.9 Authorization Codes MUST be single use is a dead letter, because it requires atomic operations at scale. Even things like password changes are not atomic in user databases of moderate size. Authorization codes might be generated quite frequently (e.g. when “immediate mode” flows are used), so a MUST for an atomic operation is unrealistic. Need proposed text. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
