Most discussions in the other thread is about protecting callbacks. How about if we look at this issue from a different angle? Instead of trying to stop session fixation, we find ways to detect it. How about if we drop a cookie?
There are many ways to add a cookie. Here is my proposal, 1. On the redirect to provider for authorization, consumer is required to drop a cookieand the content is also the same request token (e.g Set-Cookie: OAUTH_TOKEN=[Request Token]) . This cookie is on consumer domain. 2. When provider receives the call to authorize token, it's required to make a session check call by redirect to consumer. Provider passes the request token and a callback as parameters. 3. When consumer receives the session check call, it will check the cookie. If the token in the cookie matches the parameter, it will call the callback to notify provider to proceed. Otherwise, an attack or lost cookie is detected. OAuth signing and none can be used for security and replay prevention. 4. When provider receives the callback from consumer, it knows the session is valid and normal OAuth dance continues. The attacker can ask victim to click on the link but it's very hard to drop a cookie on consumer's domain in victim's browser. The major drawback of this approach is that it practically makes OAuth flow 4-legged. I am sure there are holes ... Zhihong --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
