What about non-http return uri's, or client-localhost, such as someapp://app/?code=foo
http://localhost:87345/?code=foo HTTPS makes sense when you're talking between two web servers, but it seems to fall apart otherwise. I think SHOULD is appropriate here. -- Justin On Fri, 2011-03-25 at 16:03 -0400, Eran Hammer-Lahav wrote: > Unless someone has an objection, I'll make the change from SHOULD to MUST. > > EHL > > > -----Original Message----- > > From: Phil Hunt [mailto:phil.h...@oracle.com] > > Sent: Friday, March 25, 2011 12:42 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG; Chuck & Mara Mortimore > > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
