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