Regarding the message: http://www.ietf.org/mail-archive/web/oauth/current/msg05762.html (sorry I somehow lost the message in my email).
This issue is theft of the authorization code during the redirect. Authenticating the client is an important feature and goes a long way, but it is not sufficient since in many cases, the client_id/client_secret will likely be hard coded and relatively easy to deduce (e.g. mobile client apps). Of course a strong client authentication won't have this issue. This makes many consumer situations very susceptible to an attack where the authorization code is intercepted. For more information look at the SAML Artifact issues in section 6.5 (specifically stolen artifact, replay, etc) of this document: http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf There are a number of remediations suggested (small lifetime, single use), but the foundational one is confidentiality of the exchange (TLS). Hence the recommendation that the return of an authorization code be kept secure with a MUST for TLS. Phil phil.h...@oracle.com On 2011-03-24, at 7:22 PM, Chuck Mortimore wrote: > > On Mar 24, 2011, at 6:36 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: > >> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >>> Of Chuck Mortimore >>> Sent: Monday, March 14, 2011 6:10 PM >> >>> 1) I'd vote for dropping the following from 1.4.2. In turn I'd discuss >>> some of >>> the security considerations, such as difficulty of protecting a >>> client_secret in >>> almost all use-cases of this profile. >>> >>> "Implicit grants improve the responsiveness and efficiency of some >>> clients (such as a client implemented as an in-browser application) >>> since it reduces the number of round trips required to obtain an >>> access token." >> >> Why drop it? What about it isn't accurate? > > It's accurate, but my opinion is it sends the wrong message. It's clearly > the less secure of the response types. By positioning it as the most > performant people may find that attractive and make the wrong security > decision. > > >> >>> 2) Section 2.1, we should MUST TLS even for Authorization Code. >> >> Why? What's the attack vector? > > See Phils comment on past experience with artifact bindings. Spec should > default for security always on, and let deployments that don't want to use > HTTPs simply be non-conformant. > >> >>> 3) Section 4.1.3 - not clear to me why redirect_uri is REQUIRED since in >>> 4.1.1 >>> it's "REQUIRED unless" >> >> The client should always confirm where the code was sent to. It can omit the >> redirection is one was provided but should tell the server where it went to. >> This is more consistent on the verification side, but if the original flow >> designers want to chime in (Dick, Brian, etc.?), I'm open to change this. >> >>> 4) Section 4.2.2 - when did we drop refresh_token? I assume this goes >>> back to disagreement on how best to handle native clients. I'd prefer it to >>> simply reference 5.1 and leave what is issued up to the security profile of >>> the >>> particular deployment as to what is issued. >> >> -08 June 2010. >> >> This has been decided for a long time. I'm not eager to change it. > > Thanks - I can live with it. Unfortunately we still seem to be fragmenting > on the native client approach. Good topic for IIW I suspect > > -cmort > >> >> EHL >> >> > _______________________________________________ > 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
