> > 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. > > The significant advantage of this approach is that the Consumer App knows > the Request Token and Secret before they specify the Callback URI so they > can encode state into the callback and operate in a stateless manner – which > is important for scalability.
The request token can be stored in a cookie or some other parameter that provides XSRF protection vis-a-vis the callback URL. This allows the consumer to remain stateless by doing the right thing. > > An advantage of this approach for the Service Provider is that there is no > extra state that has to be maintained between the Request Token and > Authorization steps so the SP’s Request Token format should not need to > change to maintain stateless operation. > This does not have to change. The SP can encode the callback URL in the request token itself. > > > I believe Consumer Apps can operate in a stateless manner with OAuth Core > 1.0 so it would be a significant disadvantage to break this ability in a > security fix. My guess is that it would require very substantial changes to > a Consumer App’s architecture if it had to switch from a stateless to a > statefull mode to support a security fix. There is no need for such radical changes as described above. > > > > The Callback URI still appears in the authorization step, but changing it > does not help an attacker since that would cause the subsequent request to > obtain an Access Token to fail. Possibly. But we would have to think carefully about that. > > > > > > > > 6.1.1. Consumer obtains a Request Token – UNCHANGED from 1.0 > > > > 6.1.2. Service Provider issues an unauthorized Request Token – UNCHANGED > from 1.0 > > > > 6.2.1. Consumer directs the User to the Service Provider – UNCHANGED from > 1.0 > > > > 6.2.2. Service Provider authenticated the User and obtains consent – change > warning text in some situations > > > > 6.2.3. Service Provider directs the user back to the Consumer – insert > “verifier” into callback, or display “verifier” > > > > 6.3.1. Consumer requests an Access Token – CHANGED to include Callback URI > > > > 6.3.2. Service Provider grants an Access Token – UNCHANGED from 1.0 at the > protocol layer, but the SP performs an extra check (that the Callback URI > matches) before responding > > > > > > > > The OAuth wiki (http://wiki.oauth.net/OAuth-Session-Fixation-Advisory) > compares proposed solutions with 10 questions. 9 answers for this proposal > (callback with access token request) are the same as the “signed callback > URLs” (callback with request token request) solution. The only difference is > supporting a smooth upgrade path from 1.0 to the fixed protocol. This > proposal can certainly support a smooth upgrade path, but it cannot use the > presence of oauth_callback when obtaining a Request Token to indicate > support for the new version. Any other indication would do. A different > Request Token URI is one option. > > > > > > > > James Manger > > [email protected] > > Identity and security team — Chief Technology Office — Telstra > > > > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
