Re: How API will works after OAuth?
Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers On Feb 5, 4:59 am, Cameron Kaiser spec...@floodgap.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. I appreciate the consideration. :) -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --
Re: How API will works after OAuth?
I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. -Joel On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones --- -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: How API will works after OAuth?
2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones --- -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- http://stut.net/
Re: How API will works after OAuth?
Guys,
We all know that base-auth is a gold for our app and when we think about
another way like OAuth we get mad
BUT
If the Toke had infinit life time (probabily will do), so the big poblem
transform in a little problem with 3 steps:
1-Your Webapp redirect the user to Twitter Web Site (Authentication)
2- User put username and password
3- Twitter redirect again the user for your Webapp authenticated.
For non-web app it a little different but easy any way...
It's not a big deal...
The most important point is the life time of token... bring OAuth and let's
made this happen !!!
On Thu, Feb 5, 2009 at 2:48 PM, Stuart stut...@gmail.com wrote:
2009/2/5 jstrellner jstrell...@urltrends.com:
I was just thinking this, and then I read your post. It would be good
to see a trusted apps section somewhere on your site, and those
application could use Basic Auth. If they don't want to go through
the process of being a trusted app, then they can use OAuth.
Just something to think about. Could earn twitter some $$$ too.
Could also land them in a world of pain. I wouldn't want Twitter to
endorse any product that wasn't theirs, and I doubt they would want to
either. Too risky.
-Stuart
On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote:
Thanks for the feedback, guys. We'll consider extending Basic Auth's
life, or maybe granting a stay of execution to known-good apps. At the
very least, we'll try not to pull the rug out from under anyone.
funkatron wrote:
Agreed. I do believe that the use of HTTP Basic Auth was key to the
quick growth of the 3rd-party app community of Twitter, as the auth
scheme is so well-understood and supported. This may or may not be as
important at this point business-wise, as I suspect the Twitter
userbase is large enough to overcome a fair bit of lazy user intertia.
I wonder if we will see a lot less interesting API hacking (the good
kind), though, and I think that would be a shame.
While OAuth makes a ton of sense for website-based apps, it's kind of
another kettle of fish for locally-hosted apps (desktop and mobile).
Moving to OAuth-only is problematic for us for these reasons:
1. it complicates (and confuses) the process for users: instead of
entering a username and password -- a well-understood, common process
-- now the app has to push the user to a web site which hopefully
explains what's going on decently. This works okay for web dorks like
us, but I guarantee your avg user is going to find this confusing.
Maybe not as confusing as OpenID, though.
2. updating locally-hosted apps to use a new authentication system is
an issue of getting thousands (or higher orders) of users to upgrade.
6 months may not be enough, even for currently active applications.
Stuff in development *cough*like mine*cough* now could find themselves
having to toss out a ton of code they're knee-deep in right now.
Yucky.
My preference would be to *not* see HTTP Basic Auth go away in the
foreseeable future. If that's not reasonable or possible, the 6-month
window (even given that the countdown may not start for a few
months) is pretty tight for comfort, and extending it would be much
preferred.
Note: One might wonder why I only mention these issues in the context
of local apps rather than web apps. I think the expectations and user
behavior tendencies are fairly different in the desktop and mobile app
space, and there are a number of ways malware is detected and
contained in this area. The web app space is a lot more open and easy
to exploit, and likely will be unless the whole paradigm changes.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote:
I'm still (softly) repeating the hope that this will be extended,
even if
the Basic Auth API remains deprecated and static. An OAuth workflow
is
constrained for desktop apps, and for apps that aren't or can't use a
web
browser (in my case, text-mode twitter clients; other cases include
all those
little curl scripts posting monitoring information, task status,
etc.), OAuth
won't work at all.
I fully support OAuth, but where appropriate. I think Ed Finkler said
it
best when he said the breadth of Twitter applications currently
extant
wouldn't exist were it not for a low barrier to entry. OAuth makes
sense
in many places, but it doesn't make sense everywhere, and I hope
alternate
methods of authentication remain possible even if they are
intentionally
limited to steer preferred traffic to an OAuth workflow. Otherwise I
suspect
the ecosystem outside the browser will be greatly reduced.
--
personal:
http://www.cameronkaiser.com/--
Cameron Kaiser * Floodgap Systems *www.floodgap.com*
ckai...@floodgap.com
--
Re: How API will works after OAuth?
I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Something like that would almost certainly need *some* kind of app key, but we can speculate on that when the time comes. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- You only live twice. ---
Re: How API will works after OAuth?
We all know that base-auth is a gold for our app and when we think about another way like OAuth we get mad BUT If the Toke had infinit life time (probabily will do), so the big poblem transform in a little problem with 3 steps: 1-Your Webapp redirect the user to Twitter Web Site (Authentication) 2- User put username and password 3- Twitter redirect again the user for your Webapp authenticated. Right, for webapps this is a bit of pain but it's still workable into a workflow since you're still in a browser. The point Ed and I were making is that for *local* or *desktop* apps, you might not be anywhere near a browser or browser-like-thing at all, so OAuth would either be a serious constraint or actually not possible. But you're quite right for third-party webapps. It hurts a bit, but it is workable, and the benefits outweigh the disadvantages. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- FOOLS! I WILL DESTROY YOU ALL! ASK ME HOW! -- Girl Genius 8/29/07
Re: How API will works after OAuth?
I'll keep that in mind as an option, but it's not particularly user-friendly. Basic Auth lets users use the password they know; OAuth keeps users from having to worry about passwords at all. This setup requires users to keep track of some other strange value. Developers understand it, so it's a fine setup for a site like GitHub, but it doesn't seem like a good approach for a more general and potentially non-technical user base. Lucas Araujo wrote: I agree, remote key is a very cool feature. Lucas Araujo FriendFeed-as3 - An Actionscript 3 version of Friendfeed API http://code.google.com/p/friendfeed-as3/ On Thu, Feb 5, 2009 at 09:37, Ninjamonk dar...@stuartmedia.co.uk mailto:dar...@stuartmedia.co.uk wrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers On Feb 5, 4:59 am, Cameron Kaiser spec...@floodgap.com mailto:spec...@floodgap.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. I appreciate the consideration. :) -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com http://www.floodgap.com* ckai...@floodgap.com mailto:ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender -- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: How API will works after OAuth?
So, what happen if this third party expose to others app this generated key? They will acess your account too? If this key can be just used for one app (maybe lock for one IP) the user will need generated always a new key for one app? (Go to twitter page, log in, acess New Keys, generate a new key, and give to the app) On Thu, Feb 5, 2009 at 10:37 AM, Ninjamonk dar...@stuartmedia.co.uk wrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers -- -- Analista Desenvolvedor www.espacodj.com
Re: How API will works after OAuth?
Hi Matt, Thx for answer... OAuth isn't hard ;) A couple of days i have learned some about it and put this on my TestApp to see how works. I'm glad to see that You guys worrie about the final user. Let's bring it on... We had just to generate our api_key and secret, and sort all parameters of the method (including api_key and secret) to creat a signature... (basically of course) So... don't worrie with us (developers) On Thu, Feb 5, 2009 at 4:33 PM, Matt Sanford m...@twitter.com wrote: Hi Gustavo et al, This is the problem with re-use systems like both Basic Auth and the FriendFeed token system. Every application uses the same token so you turn them all off at once (like a password change). Even if we give out one key per application (like OAuth) your requests can be intercepted and the credentials re-used (unless SSL is required). This sort of re-use is not a problem in OAuth where requests are signed using a secret and include a time stamp and a random value (nonce). Since the nonce can't be re-used this even guards against replay attacks.I know OAuth is hard. I've implemented the server side, a Scala test library and a sample Rails app (blog post coming soon). Having said that, all of the times I've wondered why it has to be so difficult I've come up with an attack scenario that means that part can't be dropped. I want to try and keep up Basic Auth as long as it's needed, but on the other hand I don't want to be like Microsoft who keep around LANMAN as an attack vector for years on end. It's a tough balance between encouraging developers and protecting our users. Thanks; — Matt On Feb 5, 2009, at 10:13 AM, Gustavo Melo wrote: So, what happen if this third party expose to others app this generated key? They will acess your account too? If this key can be just used for one app (maybe lock for one IP) the user will need generated always a new key for one app? (Go to twitter page, log in, acess New Keys, generate a new key, and give to the app) On Thu, Feb 5, 2009 at 10:37 AM, Ninjamonk dar...@stuartmedia.co.ukwrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers -- -- Analista Desenvolvedor www.espacodj.com -- -- Analista Desenvolvedor www.espacodj.com
Re: How API will works after OAuth?
I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. @Cameron, I would also agree that an app key would be required in this case, specifically so that Twitter could revoke Basic Auth logins from that app if they were found to be violating the terms of the contract. If that key was disabled, no one would be able to use Twitter from that app, and thus, the app maker would make sure that they were in compliance. -Joel On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth
Re: How API will works after OAuth?
2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully
Re: How API will works after OAuth?
Stuart , In my first reply to this subject, I indicated that it could be a paid model for them, and I still think it could. Either way, I see them needing to use a key of some sort for desktop applications. Twitter would still need to be involved though, if you want to prevent sharing of said key and you want the user to be able to revoke it. -Joel On Feb 5, 11:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03
Re: How API will works after OAuth?
Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. JD On Thu, Feb 5, 2009 at 12:02 PM, jstrellner jstrell...@urltrends.comwrote: Stuart , In my first reply to this subject, I indicated that it could be a paid model for them, and I still think it could. Either way, I see them needing to use a key of some sort for desktop applications. Twitter would still need to be involved though, if you want to prevent sharing of said key and you want the user to be able to revoke it. -Joel On Feb 5, 11:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic
Re: How API will works after OAuth?
On Feb 5, 10:38 pm, James Deville james.devi...@gmail.com wrote: Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? I'm not sure people have said Twitter would have a problem. I've personally expressed some problems specific to applications I develop. Much of what I said would apply to desktop apps for Flickr too, but Flickr has never offered anything but OAuth (AFAIK). In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. SSL has been available in the API for as long as I recall, and is in fact officially recommended, AFAIK. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: How API will works after OAuth?
On Thu, Feb 5, 2009 at 7:52 PM, funkatron funkat...@gmail.com wrote: On Feb 5, 10:38 pm, James Deville james.devi...@gmail.com wrote: Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? I'm not sure people have said Twitter would have a problem. I've personally expressed some problems specific to applications I develop. Much of what I said would apply to desktop apps for Flickr too, but Flickr has never offered anything but OAuth (AFAIK). I thought I had read that concern earlier in the thread. In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. SSL has been available in the API for as long as I recall, and is in fact officially recommended, AFAIK. Didn't realize that... (Off to the editor...) -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
How API will works after OAuth?
Hello Guys, Matt and Alex... We need to understand how OAuth will affect ours app's... Twitter authentication with username and password will totaly stop work? How many days we will have to change our app's? And for me the most important question is, OAuth before copmleted authentication for user, return to my app some Token Auth... This Token had some time o live right? What time is it? One day? One Week? One Month? This is really important for my app that was based on MO/SMS ! Once the user made the full process to authentication, i think will be better for us (developers) to receive a token with bigger time of life! Best Regards and sry my bad english. -- Analista Desenvolvedor www.espacodj.com
Re: How API will works after OAuth?
2009/2/4 Gustavo Melo pipoc...@gmail.com: We need to understand how OAuth will affect ours app's... Twitter authentication with username and password will totaly stop work? How many days we will have to change our app's? And for me the most important question is, OAuth before copmleted authentication for user, return to my app some Token Auth... This Token had some time o live right? What time is it? One day? One Week? One Month? This is really important for my app that was based on MO/SMS ! Once the user made the full process to authentication, i think will be better for us (developers) to receive a token with bigger time of life! I don't speak for Twitter but from what I've heard so far... Basic auth will continue to work for about 6 months so you'll have plenty of time to change your apps to work with OAuth. I would hope that OAuth tokens will last forever as they do with Flickr for example. If not then it's going to be annoying for both users and developers. Nobody has ever suggested they'll be time limited. -Stuart -- http://stut.net/
Re: How API will works after OAuth?
Sorry for chiming in on this late by I have been working with @mrtall on the OAuth code. Your first question about allowing OAuth and Basic Auth to co-exist is one we've covered a few times in this group but it's sort of buried in the documentation [1]. We plan to keep Basic Auth available for six months after the public launch of OAuth. The idea with this overlap period is so people have plenty of time to migrate applications. I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones ---
Re: How API will works after OAuth?
Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiser spec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones ---
Re: How API will works after OAuth?
Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones --- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: How API will works after OAuth?
Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. I appreciate the consideration. :) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --
