There is absolutely nothing in the OpenID/OAuth authentication methods that guarantees an individual signing-in through them is indeed a unique user. OpenID provides a bit more data in a form of a certificate (user name, email address, and notary) than OAuth's valet key authentication, but that alone isn't enough to prevent voting fraud. Using the word fraud in this sense is a bit severe in my opinion, maybe abuse is more suitable? Regardless, let's see what other information you could use in your web application and what that means for your voting system:
- IP address: Not suitable as most users get their IP assigned by a DHCP server and is dynamic (can be assigned to another user later on, or the same user can request a new one), different users might be accessing your website through the same IP (organisations and others using proxy servers, mobile IPv6 users tunneling through an IPv4 broker, and so on), or the same individual could use other means of accessing your website with a different IP (TOR network, VPN,...)
- Session ID: This consists of a session cookie (or some form of a session persistent request query value in cookie-less sessions), commonly also user-agent string (browser's identification string), and IP that we already covered. None of these (on their own, or session as a whole) guarantee a unique user is signed in as they can simply switch to different browsers, clear user session by deleting cookies, or even change browser's signature. All of which can invalidate the user session and a request for a new one would be made.
- Referral string: Not suitable on its own as it can easily be spoofed or simply reused many times.
This leaves you at either:
- Trusting Facebook and Twitter to do their own detection of multiple per-user accounts,
- Requesting an additional user authentication that would try to detect such abuse (might be impossible to do any better than what is already in place with Facebook and Twitter),
- Change to voting with a ballot (invitation only one-time voting), or
- Account for possible voting abuse when presenting results (such as weighted averages).
All latter three options are rather tricky to implement and might not be within your project's budget, which is - at the end of the day - the most decisive factor on which of these options could or should be implemented.
On a side note, I wanted to give you a good example for the weighted average, but the problem is that all systems that care about the validity of these methods intentionally don't publish their inner workings, to prevent further abuse by circumventing the system in place. One of the websites that uses such voting mechanics and is known to put a lot of effort into it is IMDB (you be the judge on how effective that is, I'll reserve my comments), and there are many others with altogether different implementations. Even StackExchange has some sort of serial voting prevention, but details about it are also rather scarce.