Agreed. I think that's something a lot of people misinterpret. OAuth is for API authorization, not Twitter authentication.
Ryan On Thu, Oct 22, 2009 at 9:35 AM, Andrew Badera <[email protected]> wrote: > > Keep in mind too, OAuth is really for authorizing, not authenticating > ... may sound pedantic, but it's a pretty substantial difference. The > authentication stuff is more of an after thought ... > > ∞ Andy Badera > ∞ +1 518-641-1280 > ∞ This email is: [ ] bloggable [x] ask first [ ] private > ∞ Google me: http://www.google.com/search?q=andrew%20badera > > > > On Wed, Oct 21, 2009 at 10:16 PM, shawninreach <[email protected]> > wrote: > > > > Yeah exactly what i was thinking but i thought this was the whole > > point of oauth to not need someones pass to authenticate with an app. > > Oauth is basically just a setup where it authenticates an app to use > > an account, but its not something that I can use to implement a full > > login system to my own app? > > > > On Oct 21, 9:58 pm, JDG <[email protected]> wrote: > >> You could have the user sign in with their username and password and > make a > >> call to account/verify_credentials. If it returns 200, you know you can > get > >> the access token. > >> > >> > >> > >> On Wed, Oct 21, 2009 at 18:41, shawninreach <[email protected]> > wrote: > >> > >> > Ok so you guys are saying store the access token in the db. Im getting > >> > hung up on how you would authenticate this user at a later point > >> > without making them reauthenticate through twitter to make sure who > >> > they say they are. > >> > >> > First Authentication > >> > User comes to site -> twitter auth (type in username/pass) -> twitter > >> > auth (do you want to allow app) -> back to site (store access tokens) > >> > >> > Later Authentication on a diff computer per say > >> > User comes to site -> twitter auth (type in username/pass) -> ?? (do > >> > something with access token) ?? -> back to site > >> > Something like if user and pass are valid then get the access token > >> > from the db and start doing w/e you wanted to do? Is this the flow > >> > that im missing? > >> > >> > On Oct 21, 8:08 pm, ryan alford <[email protected]> wrote: > >> > > The access token doesn't expire. It's also specific for the user. > >> > > There is no reason for you to get rid of it. > >> > > You should store it with a relation to the username. The user should > >> > > not be forced to re-allow every session. > >> > >> > > On Oct 21, 2009, at 7:44 PM, shawninreach <[email protected]> > >> > > wrote: > >> > >> > > > Im a little confused on why some people are saying you want to > store > >> > > > the access token after you get it. Dont you just want to keep it > in > >> > > > the session until the session expires or the user clears cookies? > I > >> > > > understand how to use the access token, im just confused on after > the > >> > > > session is expired your going to need to make the user click "I > Allow" > >> > > > later again and theres nothing that can be done about that and you > >> > > > request new tokens so why store them in the database at all. > Basically > >> > > > im just trying to understand this process a bit more so I can > safely > >> > > > store only what I absolutely need to. Thanks guys for the help! > >> > >> -- > >> Internets. Serious business. > > >
