0
votes

The task is simple. I want to use Sign In With Twitter as the user's credentials, allowing them to access restricted areas of the site and have their actions be associated with their account.

I am able to sign them in through Twitter. I get back an id, username, oauth tokens, secret tokens, ...

Now let's say the user then makes a site-specific action, like vote on a survey. I want to attribute the vote to their account.

What should I send to the server to prove that the vote is coming from the twitter user that it says it is?

For example, is it enough to send back the twitter id and the vote? Can others get a hold of this id and then start making votes on the user's behalf?

Should I send twitter id, oauth tokens, and secret token to my server? Again, how do I verify that these credentials are valid? Do the server need to make a call out to twitter to verify these credentials after every site-specific action? That seems excessive.

Do I have the server verify the credentials once and send back some random session key and then just verify the session key after each request for the remainder of the session?

This sort of thing has been implemented on thousands of sites, so just wondering what that common sense solution is. Sorry if this question has been asked before. In that case, reference to the answer would be greatly appreciated.

Also, I'm on node.js and using hello.js in case there's a stack-specific solution

Thanks

1
I realize there's an inherent issue with my assumption. hello.js allows me to do authentication all on the frontend (with the help of a 3rd party proxy server). Because my server never sees the token exchanges, it relies on the client to tell it that it's been authenticated, which is where I'm corned with this approach. Instead, I ended up using passport.js which is backend authenticationkane

1 Answers

0
votes

Your session key idea is fine. It will guarantee the association between further requests (e.g. Vote) and the Twitter user ID. The only problem if there is a man-in-the-middle then they capture the session key and can replay requests. This is solved by using HTTPS, which guarantees that no one has messed with an incoming request and hence guarantees the association with a user. And since the session key is short lived there is no chance they can be used in future attacks.