Re: oAuth Good Practice
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 > > On Feb 17, 8:58 pm, Alex Payne 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.
Re: oAuth Good Practice
On Feb 17, 8:58 pm, Alex Payne 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.
Re: oAuth Good Practice
Hi Alex, Thanks for the prompt reply. I was really keen on never to have store credentials for our service (i.e, have credentials to log in to our site - it means we don't have to have an account creation process and we don't have to securly store extra usernames and passwords). Our cookies will be long lived, however there is no guarantee. I like the idea of seamlessly authenticating against twitter as essentially twitter is the most important part of twe2. Kind Regards, Paul. 2009/2/17 Alex Payne > > We discourage any workflow that frequently sends users to Twitter to > re-authorize an OAuth application. This really isn't the way OAuth is > intended to be used. > > As to your second point: yes, do NOT store keys in unencrypted cookies. > > On Tue, Feb 17, 2009 at 12:54, Paul Kinlan wrote: > > Hi Alex, > > > > Erm, yes and no. I understand from our service point of view that we can > > hold on to the access key for as long as it is valid, however, we are > trying > > to create a no username system so we need to keep track of our own > > session/auth cookies, which could get cleared out regularly. What > happens, > > then is that to log in we will need to send them to the twitter authorise > > app to access the data each time they clear their cookies. So my > question, > > is it acceptable? I think it is, just wondering if you guys "support" > this. > > > > One other question I am presuming the access keys should never be exposed > > publically? For instance it would not be a good idea to store the key in > a > > cookie (we are not doing this anyway). > > > > Kind Regards, > > Paul Kinlan. > > > > 2009/2/17 Alex Payne > >> > >> Our access tokens should be long-lived enough that users shouldn't > >> have to come back to Twitter. Does that answer your question? > >> > >> On Sat, Feb 14, 2009 at 00:39, Paul Kinlan > wrote: > >> > Hi Guys, > >> > > >> > I am working developing twe2's oAuth support and I have a quick > question > >> > for > >> > the group. Obviously, oAuth solves us having to store the twitter-ers > >> > username and password on our system by delegating the authentication > out > >> > to > >> > twitter, however, for the past couple of services I have created, the > >> > twitter username and password has been the only form of identification > >> > on > >> > our services, basically meaning that there is no seperate login > account > >> > for > >> > our service. > >> > > >> > So my question is it acceptable whenever the users' sessions on our > site > >> > expires to redirect the user to the oAuth "allow twe2 access" page at > >> > twitter if they need to login to our site? Obviously if they never > login > >> > to > >> > the site again the access_token may still be valid (unless they remove > >> > our > >> > app from their account) and the backend software still works like > >> > normal, > >> > but if they re-accept our application this will refresh the access > token > >> > but > >> > I am ok with that. > >> > > >> > On a side note, the "Allow Access" page says the following "The > >> > application > >> > Twe2 by Twe2 Limited would like the ability to access and update your > >> > data > >> > on Twitter". We are read only application it should read "The > >> > application > >> > Twe2 by Twe2 Limited would like the ability to access your data on > >> > Twitter" > >> > > >> > Kind Regards, > >> > Paul Kinlan > >> > > >> > Twe2 Ltd - www.twe2.com > >> > > >> > >> > >> > >> -- > >> Alex Payne - API Lead, Twitter, Inc. > >> http://twitter.com/al3x > > > > > > > > -- > Alex Payne - API Lead, Twitter, Inc. > http://twitter.com/al3x >
Re: oAuth Good Practice
We discourage any workflow that frequently sends users to Twitter to re-authorize an OAuth application. This really isn't the way OAuth is intended to be used. As to your second point: yes, do NOT store keys in unencrypted cookies. On Tue, Feb 17, 2009 at 12:54, Paul Kinlan wrote: > Hi Alex, > > Erm, yes and no. I understand from our service point of view that we can > hold on to the access key for as long as it is valid, however, we are trying > to create a no username system so we need to keep track of our own > session/auth cookies, which could get cleared out regularly. What happens, > then is that to log in we will need to send them to the twitter authorise > app to access the data each time they clear their cookies. So my question, > is it acceptable? I think it is, just wondering if you guys "support" this. > > One other question I am presuming the access keys should never be exposed > publically? For instance it would not be a good idea to store the key in a > cookie (we are not doing this anyway). > > Kind Regards, > Paul Kinlan. > > 2009/2/17 Alex Payne >> >> Our access tokens should be long-lived enough that users shouldn't >> have to come back to Twitter. Does that answer your question? >> >> On Sat, Feb 14, 2009 at 00:39, Paul Kinlan wrote: >> > Hi Guys, >> > >> > I am working developing twe2's oAuth support and I have a quick question >> > for >> > the group. Obviously, oAuth solves us having to store the twitter-ers >> > username and password on our system by delegating the authentication out >> > to >> > twitter, however, for the past couple of services I have created, the >> > twitter username and password has been the only form of identification >> > on >> > our services, basically meaning that there is no seperate login account >> > for >> > our service. >> > >> > So my question is it acceptable whenever the users' sessions on our site >> > expires to redirect the user to the oAuth "allow twe2 access" page at >> > twitter if they need to login to our site? Obviously if they never login >> > to >> > the site again the access_token may still be valid (unless they remove >> > our >> > app from their account) and the backend software still works like >> > normal, >> > but if they re-accept our application this will refresh the access token >> > but >> > I am ok with that. >> > >> > On a side note, the "Allow Access" page says the following "The >> > application >> > Twe2 by Twe2 Limited would like the ability to access and update your >> > data >> > on Twitter". We are read only application it should read "The >> > application >> > Twe2 by Twe2 Limited would like the ability to access your data on >> > Twitter" >> > >> > Kind Regards, >> > Paul Kinlan >> > >> > Twe2 Ltd - www.twe2.com >> > >> >> >> >> -- >> Alex Payne - API Lead, Twitter, Inc. >> http://twitter.com/al3x > > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: oAuth Good Practice
Hi Alex, Erm, yes and no. I understand from our service point of view that we can hold on to the access key for as long as it is valid, however, we are trying to create a no username system so we need to keep track of our own session/auth cookies, which could get cleared out regularly. What happens, then is that to log in we will need to send them to the twitter authorise app to access the data each time they clear their cookies. So my question, is it acceptable? I think it is, just wondering if you guys "support" this. One other question I am presuming the access keys should never be exposed publically? For instance it would not be a good idea to store the key in a cookie (we are not doing this anyway). Kind Regards, Paul Kinlan. 2009/2/17 Alex Payne > > Our access tokens should be long-lived enough that users shouldn't > have to come back to Twitter. Does that answer your question? > > On Sat, Feb 14, 2009 at 00:39, Paul Kinlan wrote: > > Hi Guys, > > > > I am working developing twe2's oAuth support and I have a quick question > for > > the group. Obviously, oAuth solves us having to store the twitter-ers > > username and password on our system by delegating the authentication out > to > > twitter, however, for the past couple of services I have created, the > > twitter username and password has been the only form of identification on > > our services, basically meaning that there is no seperate login account > for > > our service. > > > > So my question is it acceptable whenever the users' sessions on our site > > expires to redirect the user to the oAuth "allow twe2 access" page at > > twitter if they need to login to our site? Obviously if they never login > to > > the site again the access_token may still be valid (unless they remove > our > > app from their account) and the backend software still works like normal, > > but if they re-accept our application this will refresh the access token > but > > I am ok with that. > > > > On a side note, the "Allow Access" page says the following "The > application > > Twe2 by Twe2 Limited would like the ability to access and update your > data > > on Twitter". We are read only application it should read "The > application > > Twe2 by Twe2 Limited would like the ability to access your data on > Twitter" > > > > Kind Regards, > > Paul Kinlan > > > > Twe2 Ltd - www.twe2.com > > > > > > -- > Alex Payne - API Lead, Twitter, Inc. > http://twitter.com/al3x >
Re: oAuth Good Practice
Our access tokens should be long-lived enough that users shouldn't have to come back to Twitter. Does that answer your question? On Sat, Feb 14, 2009 at 00:39, Paul Kinlan wrote: > Hi Guys, > > I am working developing twe2's oAuth support and I have a quick question for > the group. Obviously, oAuth solves us having to store the twitter-ers > username and password on our system by delegating the authentication out to > twitter, however, for the past couple of services I have created, the > twitter username and password has been the only form of identification on > our services, basically meaning that there is no seperate login account for > our service. > > So my question is it acceptable whenever the users' sessions on our site > expires to redirect the user to the oAuth "allow twe2 access" page at > twitter if they need to login to our site? Obviously if they never login to > the site again the access_token may still be valid (unless they remove our > app from their account) and the backend software still works like normal, > but if they re-accept our application this will refresh the access token but > I am ok with that. > > On a side note, the "Allow Access" page says the following "The application > Twe2 by Twe2 Limited would like the ability to access and update your data > on Twitter". We are read only application it should read "The application > Twe2 by Twe2 Limited would like the ability to access your data on Twitter" > > Kind Regards, > Paul Kinlan > > Twe2 Ltd - www.twe2.com > -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
