From Zek

The simplified steps in OAuth authorization flow are:

1. Consumer registers a key and secret with the Provider
   
2. User visits Consumer and asks to import Provider data
   
3. Consumer generates request token and redirects User to Provider authorization page
   
4. Provider asks User for login
   
5. Provider asks User for approval
   
6. Provider generates authorization token and redirects User to Consumer
   

This scenario allows a session fixation attack because it fails to require a login before a request token is generated. A simple fix would be to require a login on the Provider to start the authorization process.


Then a new authorization flow would look like this:

1. Consumer registers a key, secret, and request token page with the Provider
   
2. User visits Consumer and asks to import Provider data
   
3. Consumer redirects User to Provider authorization page
   
4. Provider asks User for login and is redirected to Consumer request token page
   
5. Consumer generates request token and redirects User to Provider authorization page
   
6. Provider asks User for approval
   
7. Provider generates authorization token and redirects User to Consumer
   

While it may appear to contain more steps, 4-6 will actually appear seamless if the user is logged in to the Provider prior to starting the flow. The redirect at step 4, from the Provider to the Consumer, will break any false starting position the User may have originated from. Redirection through callback manipulation is a common method of session fixation attacks. In the new authorization, in order to obtain a valid request token, an attacker must first compromise the very account on the Provider that he is trying to gain access to through a OAuth session fixation attack. This makes all session fixation attacks fail.

Most importantly, this solution does not add additional steps for the User or unduly burden either the Provider or Consumer. By placing the generation of a request token between two automatic redirects to secure pages on both sites we eliminate poisoning the stream while still allowing optional secure dynamic callbacks with the final authorization token.

Desktop apps that choose not to handle callbacks can verify by using the authorization token in the password field.

Please pay close attention to the fact that I didn't say anything about pin numbers, Captcha images, stronger encryption, more tokens, less tokens, or nonces. If OAuth worked before the session fixation alert, then it works the same using the new authorization flow.

I also believe that using single-attempt tokens should not be optional. This could be done by requiring the Provider to logout the User after an authentication attempt, successful or not.