On Wed, Apr 22, 2009 at 3:16 PM, Yogesh <[email protected]> wrote: > > Thanks Leah, I really appreciate that you are responding so fast. > > On Apr 22, 3:09 pm, Leah Culver <[email protected]> wrote: > > On Wed, Apr 22, 2009 at 3:04 PM, Yogesh <[email protected]> wrote: > > > > > On Apr 22, 2:50 pm, Leah Culver <[email protected]> wrote: > > > > The access token lasts forever: > > > > > So how is it different from OpenID, if you got the access token once > > > and if it is valid forever. > > > > I'm not really sure what you're asking...? > > We can forget about this for now. > > > > > > > > > Isn't this is a big security concern, as next time the consumer is > > > going to send only the access token to the service provider > > > and this is even without the actual user knowing about it. > > > > This is significantly better than having the consumer know your password > for > > the site. The service provider should have a way for a user to unallow > > tokens if they like. Also, service providers can set an expiration - > Twitter > > just chose not to. > > > > > > I totally understand it is better then the consumer knowing the > password, but the access token is > a combination of username and password anyway. > > So what happens if the service providers start setting an expiration. > The consumer has built an application > by assuming the service provider is not expiring the token.
The consumer should handle any authentication errors gracefully. If for some reason the access token stops working, the consumer should prompt the user to log in again. > > > > > > > If understand it right every token has to expire, the service provider > > > will make sure that any token that it is issuing will expire > > > sometime, > > > leave a token which doesn't expire at all leaves a big security hole. > > > > Again, this was Twitter's choice and is probably still better than > allowing > > a site to have user's password. As long as the user can disallow the > token > > from Twitter, this is fine. > > > > Agreed. But if the user's go back and again allow the consumer from > the token will it be the same > access token or a different one. The reason I am asking this is if the > consumer uses that access token as > a primary key for that user, and if the access token changes than all > the profile of that user will be lost. A new access token is provided every time the user re-authenticates. Therefore, an access token should not be used as a unique identifier for the user. A good primary key for a Twitter user would be their Twitter user ID (not the username or the email, since Twitter lets users change these). Leah > > > > > > Leah > > > > > > > > > >http://apiwiki.twitter.com/OAuth-FAQ#Howlongdoesanaccesstokenlast > > > > > > The first token you'll get back from Twitter (after the user logs in > and > > > > allows your app) is the request token. The request token only lasts > for a > > > > short amount of time. However, the first thing you'll want to do > after > > > the > > > > user returns to your site is make a request to Twitter to exchange > the > > > > request token for an access token. > > > > > > Here's an example: > > > > > >http://apiwiki.twitter.com/OAuth+Example+-+Ruby > > > > > > Leah > > > > > > > > On Wed, Apr 22, 2009 at 2:29 PM, Yogesh <[email protected]> > wrote: > > > > > > > > > Can OAuth be used to login to a consumer website?.. I am sorry > if I > > > > > > > haven't put the subject correct. But let me try to explain what > I > > > am > > > > > > > trying to achieve. I will explain this using the example of > > > > > > >www.stocktwits.com > > > > > > > > > So as we know that one can login > towww.stocktwits.comusingtwitter > > > > > > > username and password, and the advantage that stocktwits have > by > > > > > > > making a user to sign in using the twitter username and > password is > > > > > > > > > 1) Everytime a user enters his twitter username and password in > > > > > > >www.stocktwits.com, stocktwits can access the users protected > > > > > > > resources from twitter. > > > > > > > > > 2) stocktwits can create a profile for that user within the > > > stocktwits > > > > > > > for that user using his twitter username, like letting the user > > > > > > > creates his portfolio. > > > > > > > > > First Question: Iswww.stocktwits.comisgoodcandidate for > > > > > > > implementing OAuth as a consumer and twitter as a service > provider? > > > > > > > > Yes definitely. > > > > > > > > > If the answer to first question is yes, Second Question: If > > > > > > > stocktwits implement OAuth then isn't it every time a user has > to > > > go > > > > > > > to stocktwits, and stocktwits have to ask the user to "sign in > with > > > > > > > twitter" and it will take the user to twitter page where user > has > > > to > > > > > > > enter his username and password, and then user has to say yes > to > > > allow > > > > > > > access to stocktwits to access his resources. Isn't this > > > complicates > > > > > > > thing. > > > > > > > > The user doesn't need to go to Twitter every time. All you need > to do > > > is > > > > > > store the OAuth token (the access token) for the user. You can > then > > > use > > > > > this > > > > > > token over and over again to get new updates for the user. > > > > > > > If I read it correct isn't it the access token is for single use > and > > > > > valid for one/two hour (one place I read one hour and in another > place > > > > > two hour) > > > > > > > > > Third Question: How will stocktwits in OAuth case will allow > user > > > to > > > > > > > create a portfolio, because in this case stocktwits will no > longer > > > > > > > have a username to save the portfolio against. > > > > > > > > You can fetch all the info for the user (including their > username) > > > with > > > > > > their OAuth token. > > > > > > > If the OAuth token remains constant and it is not for single use > and > > > > > yes this can be done > > > > > > > > Hope that helps! > > > > > > Leah > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
