Tokens should never expire. However, you can only make that request once.
If you try to make it again with the same request request token, then you
will get the expired token error.
On Wed, Oct 14, 2009 at 12:02 AM, BlueSkies scarter28m-goo...@yahoo.comwrote:
When my application requests an
Until that happens, no user or developer is going to be happy with
OAuth in a desktop or mobile application. Sorry to be blunt, but the
user experience sucks when you're using OAuth outside the confines of
a web browser.
Not necessarily.
A UIWebView (in an iPhone app) can provide a good user
As a a software and Web site user, I consider my desktop apps mine
and Web sites theirs. I am sure that this is the mindset of most
people. We visit Web sites, and we give information to them. Yes,
they do things for us in return. Even when providing SaaS, I am still
on their site. On the other
On Oct 12, 11:44 pm, Josh Roesslein jroessl...@gmail.com wrote:
Providing an API endpoint for basic auth credential exchange for a
token would be a nice solution, but I can see it
getting abused. An attacker could bombard this endpoint trying to
guess an account's password. Protection can be
To everyone who's suggesting to embed a web view in the desktop or
mobile app, please go read this:
http://fireeagle.yahoo.net/developer/documentation/
oauth_best_practice
Specifically, ... we insist that you must not use embedded rendering
controls to present the OAuth process
Phishing
The problem is that on mobile platforms is extremely easy to simulate
a regular browser to the point a user cannot tell the difference.
Training users to expect security because it looks like a browser is
even worse than telling them to give their passwords to native apps
but be careful as to
As I mentioned yesterday, phishing, keystroke logging are some of the
attacks that a malicious app can use with OAuth.
With these attacks, a malicious app can get the password.
Of course, in the case of basic auth, every app (malicious or good)
will always get the password.
However, as I also
When my application requests an OAuth token on behalf of a user trying
to login, I have been seeing some errors:
Frequently: /oauth/access_token Invalid / expired Token
What is the length of time that a token is supposed to be valid for?
Is this documented and can it be extended? I'm sure
1. What can be improved about the web workflow?
2. What can be improved about the desktop workflow?
I think the biggest improvement that can be made is not making the assumption
people are in a web browser environment. Yes, there are workarounds, but they
are kludgey by definition.
If nothing
Speaking as a developer...
On Mon, Oct 12, 2009 at 1:01 PM, Ryan Sarver rsar...@twitter.com wrote:
1. What can be improved about the web workflow?
The desktop OAuth flow is pretty good, but the mobile device OAuth
flow is terribly painful. Since Twitter is very mobile focused, having
smooth
ugh.. found typo in my response... this sentence should read:
Each user gets an API Key which allows manipulation of
some aspects of their accounts, but *NOT* as much as knowing the actual
account password combo.
-chad
On Mon, Oct 12, 2009 at 1:37 PM, Chad Etzel jazzyc...@gmail.com wrote:
4. What could we improve around the materials for integrating OAuth
into your application?
The standard OAuth docs are pretty good, but some of the Twitter-
specific implementation isn't documented and I've implemented code
based on current Twitter OAuth behavior, but this isn't a good way to
I know that you asked about oauth workflow, but curl is really useful
for debugging purposes. I mention that because using curl with oauth
is very painful.
I'm not sure what you can do about that.
Perhaps calls using basic authentication could have very stringent
rate restrictions. This would
On Mon, Oct 12, 2009 at 2:53 PM, Jesse Stay jesses...@gmail.com wrote:
On Mon, Oct 12, 2009 at 11:01 AM, Ryan Sarver rsar...@twitter.com wrote:
1. What can be improved about the web workflow?
2. What can be improved about the desktop workflow?
3. What other models of distributed auth do you
On Mon, Oct 12, 2009 at 1:04 PM, Chad Etzel jazzyc...@gmail.com wrote:
Twitter already has something similar (one-click login):
http://apiwiki.twitter.com/Sign-in-with-Twitter
Some devs like this for the simplicity, some don't because it will
automatically use the already logged in account
1. What can be improved about the web workflow?
I'll leave this one for the web dudes.
2. What can be improved about the desktop workflow?
The UX: it's currently very complicated for the user. Much more more
complicated than basic auth. Users are unaccustomed to it. Novelty
isn't a
Please do NOT adopt anything like the Facebook model. Facebook
authentication for desktop applications is a nightmare. You have to
programatically interact with the browser and it's an enormous hassle.
I think that the OAuth flow for desktop applications is fine as-is.
Mobile apps need some
A number of older threads for reference:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/5994f3237bbb6876/
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/85dbaef35d68fc9e/
2. What can be improved about the desktop workflow?
Get Apple to integrate OAuth into the existing keychain mechanisms on
the Mac and iPhone:
http://blog.atebits.com/2009/02/fixing-oauth/
Until that happens, no user or developer is going to be happy with
OAuth in a desktop or mobile
For me, the biggest pain with Oauth is when the redirection to Twitter
gives a Twitter is busy, too many people are tweeting response. For
websites/ applications that are pretty small, each person who is
willing to try out is immensely valuable. I hate it when I loose that
person (probably
3. What other models of distributed auth do you think we could learn
from and what specifically about them?
I am happy to see username/password Basic Auth go away, but I would be
sad to see all methods of Basic Auth unavailable. Lots of other APIs
have api keys that users can use to
Isn't part of the point of oauth to teach the user they are entering
in credentials for another website into that other website?
By rebranding the twitter oauth page it gets to a point where you may
as well just ask their user/pass on your own site, and never have them
leave your
The solution for OAuth on Mobile and Desktop is easy:
Allow the app to act as the user agent when authenticating with
Twitter when requesting the token and authorizing the app.
Let me rewrite this in plain english: let the app ask for login/
password and pass it to twitter.
Users don't seem to
I wouldn't want to speak on Loren's behalf, but it seems to me that
your conclusion is similar to Loren's conclusion on this page:
http://blog.atebits.com/2009/02/fixing-oauth/
This seems like a reasonable proposal as it's a good stepping stone
toward OS. Plus it meets the as easy as
On Oct 12, 5:44 pm, Sebastian sdelm...@gmail.com wrote:
The solution for OAuth on Mobile and Desktop is easy:
snip
Let me rewrite this in plain english: let the app ask for login/
password and pass it to twitter.
snip
All we need is a simple API call where we can trade a login and
password
But it completely subverts the point of OAuth, because it lets a third party
have your password. Why even use OAuth in that case?
On Mon, Oct 12, 2009 at 19:01, Zhami stu...@zhameesha.com wrote:
On Oct 12, 5:44 pm, Sebastian sdelm...@gmail.com wrote:
The solution for OAuth on Mobile and
Ryan Sarver wrote:
1. What can be improved about the web workflow?
* On many mobile platforms--even some of the newest ones--copy paste is
unavailable, and/or users simply do not know how to do it.
* A 7-digit PIN is too long for most users to remember long enough to switch
apps and type it
Letting a mobile/desktop app grab an OAuth token using the user’s
username/password is still helpful because then they can store the token
instead of the username/password, which is a big deal when there’s no really
secure way to store it. Also, if your mobile phone/laptop gets stolen, you can
It's probably more likely that you would give your password to a malicious
site (of course, one masquerading as a legitimate client) that would store
it and use it than someone stealing your device. Moreover, many
less-than-savvy users tend to use the same password for many accounts,
including
This has already been told, but a better support for mobiles and poor/
old rendering browsers is a must. Something as simple as using the
useragent to display a nice, working and adapted login page would be a
great start.
Another point would be reliability. Is there a way that you priorize
oAuth
A good point.
Another is that OAuth provides not only authorization, but also
authentication. This would enable Twitter to shut down aps that are
misbehaving. A feature I'm sure Twitter would like not to give up.
I would also take issue with the assumption that third parties would
It is even more likely that a malicious app would direct you to a phishing site
during the OAuth flow and you wouldn’t even notice since many mobile browsers
do not show you the URL and do not implement any anti-phishing UI whatsoever.
In fact, on some phones (especially ones a few years
Providing an API endpoint for basic auth credential exchange for a
token would be a nice solution, but I can see it
getting abused. An attacker could bombard this endpoint trying to
guess an account's password. Protection can be placed to limit calls
to this endpoint by IP which might be enough
I think in the end any solution, to be the ideal solution, will need
multiple Auth access points for desktop vs. web. OAuth itself also isn't an
ideal desktop solution due to its reliance on the web. My suggestion
towards a Facebook-like solution was intended to be for web apps. It's a
great
34 matches
Mail list logo
