While this is an interesting idea, I'm prefer the existing proposal for the following reasons:
1. The ability to encode the request token and secret into the callback for client statelessness was not part of the protocol design. It is a nice side-effect at best. In fact, the callback used to be in the request token step, but moved to the authorization step only because some were concerned about forcing the server to maintain extra state. 2. The new requirement to reconstruct the callback URI is going to be as complicated for people as constructing the signature base string (which we designed specifically to bypass platform limitations in reconstructing request URIs). We all know how much problem the signature base string process is already causing. Making the protocol more complicated for clients is not an option. 3. From a security review perspective, this is an even greater departure from well known protocols in the space. While I have no attacks in mind, I would not be comfortable promoting this solution in the same timeframe for the current proposal. Before we entertain any further discussion on this as an actual option, I would like to hear from client developers with deployed applications who rely on the ability to encode the request secret in the callback for scalability to statelessness. The IETF will offer us the opportunity to look into these issues later, but for now, I don't think we should focus on theoretical use cases that were not part of the original requirements for the protocol. EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Tuesday, May 05, 2009 10:14 PM > To: [email protected] > Subject: [oauth] Re: Confirm callback when getting access token > > Brian, > > A consumer app will have a function to create a callback URI as a > string given a few parameters (request token & secret, other state). > It simply calls this function twice: once before sending the user to > the authorization URI; and once before obtaining an access token. > > A consumer does not have to reconstruct the scheme/host/port/path- > prefix components solely based on the user's request to the callback. > > I would guess the callback URI (or at least a template for a callback > URI, with a few placeholders for specific items) would be a > configuration parameter to most OAuth libraries -- precisely to allow a > person to provide the right address when there are SSL accelerators, > load balancers, auto-redirects, DNS tricks etc that the library cannot > see. The same configured callback URI template is used at both steps. > > It is possible these issues could occasionally trip-up a consumer, but > that is not a good reason to sacrifice more fundamental architectural > options (eg state management). > > > James Manger > [email protected] > Identity and security team — Chief Technology Office — Telstra > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Brian Eaton > Sent: Wednesday, 6 May 2009 2:29 PM > To: [email protected] > Subject: [oauth] Re: Confirm callback when getting access token > > > On Tue, May 5, 2009 at 5:54 PM, Manger, James H > <[email protected]> wrote: > > The Consumer App includes the Callback URI when obtaining an Access > Token, > > instead of including the Callback URI when obtaining a Request Token. > > > > The Service Provider checks that the Callback URI in the request for > an > > Access Token matches the Callback URI to which the authorizing user > was redirected. > > One interesting aspect of this proposal is that it requires consumers > to reconstruct the exact callback URL used by the service provider. > This is certainly possible, but it can be tricky. > > For example: > - what if there is an SSL accelerator that terminates the HTTPS > channel and forwards HTTP? > - what if the consumer is load balanced in such a way that the host > header changes or the port changes? > - what if the consumer uses software that automatically redirects > users to include additional query parameters? > - what if the consumer uses high-level web app development tools that > abstract away notions of URLs and parameters? > > It's possible to cope with all of those things, but it requires > different code in different environments. It takes us farther away > from protocols and libraries that just work. > > OpenID RPs are required to verify that the URL in the authn response > matches the receiving URL, but the requirements there are less strict. > The RP is able to ignore things like protocol or port or query if > they know they are irrelevant (or tricky) in the RPs environment. We > wouldn't have that flexibility with OAuth, because the consumer has to > to send the URL to the SP for verification. if the consumer screws it > up, the protocol fails. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
