It is important to distinguish between securing the resource server and securing the client. I think this is where this conversation has been somewhat broken.
If the client is user-agent based or web server based, it MUST user TLS 100% of the time when authenticating its users or delivering any scripts that may have access to any OAuth credentials (tokens, code, etc.). This goes far beyond just securing the redirection call. For example, a JS client running in the browser will not leak the access token received from the authorization server using the implicit grant because it is delivered over TLS and is in the fragment which will not be send to the server containing the script. However, if that script is served without TLS, it can be manipulated by a MITM and changed to send the access token anywhere. Same with server based clients using cookies for their own user authentication. If they don't use TLS exclusively, sessions can be hijacked and any protected resources they have access to are now potentially compromised. IOW, if the client isn't perfect all around, securing the redirection URI does not increase its security. It's like putting an armed guard at one entrance to a building with 100 other wide-open doors. It is hypocritical and irresponsible to create the illusion of client security by focusing solely on the redirection URI. IMO, a strong warning with a comprehensive explanation of the overall client security model will do much more good than putting horse blinds on and pretending that what the client does right after the callback is 'not OAuth' and something we should not care about. A MUST use TLS focused narrowly on the redirection URI does not make the web better. At best, it make one door secure, but it also has the potential of creating a false sense of security which is typically where things go terribly wrong. BTW, a profile of OAuth used primarily for login such as the proposed OpenID Connect, should make the callback use of TLS required. In that context, it is a logical extension of the server's use of TLS to provide a secure login experience. EHL > -----Original Message----- > From: Skylar Woodward [mailto:sky...@kiva.org] > Sent: Thursday, March 31, 2011 7:32 AM > To: Dick Hardt > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > > A requirement for TLS on the callback would make OAuth prohibitive for > many of our developers. The developers are usually volunteers and they are > already donating their own resources to help a non-profit (from which US law > mandates the developers cannot profit). In other cases the developers are > small firms operating in developing counties where establishing and > maintaing a valid certificate may still be a imperfect art. > > In short, a requirement like this puts the nail in the coffin of many would-be > efforts to help out. > > So as Dick identifies here, we have sufficient security around the > authorization grant by tying it client credentials. I would thus be opposed > to > the term "MUST." I also think it's helpful to have the language limit the > SHOULD to the non-user-agent cases. There's no reason we should suggest a > callback URI designed for client-side intercept to use an HTTPS url - so this > is > in the spirit of Phil's response to Justin's comment on limiting the scope of > SHOULD. > > skylar > > > > On Mar 30, 2011, at 11:19 AM, Dick Hardt wrote: > > > Thanks for pointing out my misunderstanding. I was thinking client in the > sense of the side of TLS initiating a request. > > > > I agree that requiring TLS on the callback is an unexpected change. > > > > I recall reviewing the security implications of an unsecured callback as > > being > nominal if the authorization grant is linked to the client credentials. > > > > > > On 2011-03-29, at 10:07 PM, Eran Hammer-Lahav wrote: > > > >> I think you got this backwards. We're talking about forcing developers > using the Facebook (or any other service) API to deploy their own TLS > endpoint for the incoming callback (via redirection). Every developer will > need to get a cert and deploy an HTTPS endpoint. > >> > >> That's has never been discussed. > >> > >> EHL > >> > >> From: Dick Hardt [mailto:dick.ha...@gmail.com] > >> Sent: Tuesday, March 29, 2011 9:02 PM > >> To: Eran Hammer-Lahav > >> Cc: WG > >> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt > >> > >> > >> On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote: > >> > >> > >> To clarify, I am not opposed to mandating TLS on the callback, just that if > we do, we can't ship the protocol the way it is without coming up with some > other alternative that does not require TLS deployment on the client side. > OAuth 1.0 has no such requirement and adding it in 2.0 is completely > unexpected by the community at large. > >> > >> I only recall the concern with TLS to be on the server side, not the client > side -- and I don't think that it is unexpected at all. > >> > >> > >> > >> It would be helpful to hear from some companies with large 1.0 or 2.0 > deployment on this matter? Anyone from Google, Facebook, Yahoo, Twitter, > etc.? > >> > >> When working on OAuth-WRAP, I talked to all of those companies about > using TLS, and only Facebook said that they wanted an option to be able to > not require TLS. Since then, all Facebook's new APIs which are essentially > using OAuth 2.0 run on TLS. > >> > >> > >> > > > > _______________________________________________ > > 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
