> Interesting tho, Twitter is putting a lot of trust in the third-party
> app that they won't mismange tokens. At least it's better than basic
> auth. Thanks again.
I don't think so. It's the _user_ who's asked if he trusts that third
party app to not mismanage tokens. Twitter's got nothing to do
wow awesome conversation! Answered all of my questions! Thanks
everybody!
On Oct 22, 3:29 pm, soupreme wrote:
> I see. Thanks! It sort of makes me emo to have to manage seperate
> credentials. Looking for more of a SSO solution, but thats cool.
>
> Interesting tho, Twitter is putting a lot of t
I see. Thanks! It sort of makes me emo to have to manage seperate
credentials. Looking for more of a SSO solution, but thats cool.
Interesting tho, Twitter is putting a lot of trust in the third-party
app that they won't mismange tokens. At least it's better than basic
auth. Thanks again.
On O
You could encrypt/decrypt the token in a cookie. You certainly wouldn't
want to store it in plain-text.
Or, in your database, have username, password, and access token. The user
enters their username and password to authenticate to you that they are that
user.
The "more secure" part of OAuth is
Let's say that after a user "allows" and Twitter grants an access
token which I persist my app's db, what is the best design to
authenicate this user and match them to the stored token?
If I use a browser cookie (hopefully not with the value of the user's
Twitter User Id which is public, lol) and
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 wrote:
>
> Keep in mind too, OAuth is really for authorizing, not authenticating
> ... may sound pedantic, but it's a
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: ht
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
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 a
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 wrote:
>
> Ok so you guys are saying store the access token in the db. Im getting
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/
Not sure if what I posted made sense. Basically i understand now why
to store the access token, just curious now on how a user that
connects to your app on a different computer authenticates to the
point where we believe they are a given user, then we can grab the
access token from the db and keep
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
wrote:
>
> Im a little confused
Access Tokens, in Twitter's case, do not expire. According to the OAuth
spec, they MAY expire, but do not have to. In Twitter's case, it seems they
have decided to keep an access token valid until the access granted by said
token is explicitly revoked by the user. Fetching a new access token in
eve
14 matches
Mail list logo
