Hi, Ahh, cool, I actually understood that the access token should be kept as secret as possible, but it is the "signing" process that really protects the requests as that uses the secret key etc.
>From a Twitter oAuth point of view (and from what I understand what the plan might be) I just worry, because I have several services that use twitter as an authentication mechanism, I think there are a lot of twitter services on the internet that do the same (in fact I would like to see a straw poll ;) ). These services ask for the twitter name, and password; in the future they will ask for (most likely) a twitter name, a site specific password (to log in) and the backend service of the site will use the oAuth stuff. I just think we will all be in the same situation we are in now because I strongly belive that most people will use the same password for the service that they do to use Twitter and adding in the fact that I belive most people think oAuth will mean that no passwords will ever be required they will be confused/distrusting as to why a password is required at all. I could easily use oAuth to authenticate against twitter and would never need a log in box on any of my sites (blaine/alex/matt email me off list if you want to see the demo site I have). I understand it though that you might prefer us not to have a high number of users "allowing" applications to repeatedly ask for access to the data. oAuth as an Alternative login mechanism would be awesome. I mean really awesome, no twitter 3rd party service would ever need a username and password. Kind Regards, Paul Kinlan. 2009/2/19 Blaine Cook <[email protected]> > > On Feb 17, 8:58 pm, Alex Payne <[email protected]> wrote: > > As to your second point: yes, do NOT store keys in unencrypted cookies. > > Access tokens were designed with the assumption that they should be > treated as "public", hence the existence of the secret part of the > token/secret pair. The secret should never be exposed, but there's no > reason that I'm aware of to hide the access token itself (that said, > there's no reason to go out of your way to advertise it, either). > > Of course, that doesn't help in this situation, since authenticating > users at twe2 should not be done on the basis of a single "public" > identifier. > > b.
