However, for us, we think the advisory is probably a bit over alarming.

While a token session length is useful, a determined hacker could just generate a fresh token each time they send a user into their trap.

This problem only affects apps where the evil user has an account with the consumer, i.e., a consumer user accounts gathers additional data from a provider.

Apps where a consumer user account is created along with info provided are not affected, i.e., the app uses the token as a user ID, hence no evil user could get this without having the approved token.

I think the easiest way to implement a fix if for consumers to sign a callback url in the token request, so evil.com doesn’t get the token given back to them. (This way the providers don’t have to bother registering/storing/validating various callback URLs (I would want more than 1), and I don’t have to think about notifying providers if I make any changes to my callback URL either).

Another option, as this problem only affects existing user accounts on good.com, is for good.com to also sign and pass over the username for the requesting account.

The provider displays “Hello Bob, The user ‘bob2009′ at http://www.good.com wants to access your address book, is this OK?”

Ideally, I’d have both username and callback urls signed and passed over. Though it looks like from the Wiki you have it under wraps.

The sooner you agree, the sooner Google will remove that horrendous “this application is not configured securely” warning when the user approves, set as per your advisory.

We’d like to publicly show our appreciation for Twitter’s role in helping to minimize premature publicity of this threat, even at its own expense, taking the heat as if it was their own issue in order to allow other companies to address this threat.
…