That's true, it does violate one of the tenets of OAuth. In your case, saving the access token may not be the most ideal solution, for the simple fact that you apparently ONLY deal with Twitter and you expect logins from multiple systems. You could either require OAuth at every step using "Sign in With Twitter" that would only require the user to approve access once, but would fetch a new access token every time, or you could create your OWN user system with a different user/password combination.
On Wed, Oct 21, 2009 at 20:16, 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. > -- Internets. Serious business.
