I would like to suggest a slightly different solution for the OAuth session fixation bug.
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. 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. 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. 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. 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]<mailto:[email protected]> Identity and security team — Chief Technology Office — Telstra --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
