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 -~----------~----~----~----~------~----~------~--~---
