What approaches do other OAuth providers take to this problem? Revoking all OAuth tokens on a password change/reset takes away a good chunk of the value that many people get from using OAuth.
Along the same lines, if you build a twitter app that uses Oauth and change the access from read to read/write the oauth tokens never change and won't work if you try to do a write operation. Even if you log out and log back in manually. More problematic the error is '401 - Unauthorized', blah.<p>The work around recommended by Twitter? Register a new twitter app that is read/write from the get go. :(
I guess I don't quite follow the logic here, though I'm not advanced in the ways of the web yet.<p>When you connect to a site with OAth, doesn't it require that you a) sign in using Twitter or b) are already signed in using Twitter? I would think this is necessary, otherwise people with multiple Twitter accounts, each of which use the same OAuth site, would end up with a lot of confusion.<p>So given this, Eva would have to a) sign in to Alice's Twitter account, which she can't do because Alice changed her password, or b) continue to be signed into Alice's Twitter account, while Alice changes her password, which would also be a security compromise of Twitter in general, no need to get into OAuth at that point.<p>Did I crack this thing or did I miss something?