Well as the other answers have indicated, that passing you to the OpenID provider to login is part of the specification. Also in agreement with Umesh above, Facebook provides Facebook Connect, which isn't OpenId, but allows you to authenticate users using this method.
See: Is Facebook an OpenID provider?
What I do want to add however is clarification that you don't just run off and create an OAuth based authentication system because OpenID isn't what you want to use. OAuth provides you with more than just login authentication, there's more power in there - which strangely users are unaware of. OpenId passes along your credentials and OAuth passes along access to your data. So with OpenId the website can authenticate me, with OAuth the website can authenticate me and possibly have access to all my email or my documents in Google Drive. The good thing is that you the user has to explicitly allow this access.
But erring on the side of privacy you'd want to build a compelling case for an application that needs the power of OAuth. Like the picture in the article below, one's the different between asking for a notarized letter to prove your identity, and asking for a valet key to prove your identity.
A valet is OAuth, I need them to take my car and park it in the parking lot, so I give them a valet key. It can't open the glove compartment or the trunk, but they can open the driver's side door and start the ignition - which is all I need them to do, and no more. However I don't give the cashier at the grocery my valet key when I'm paying with a personal check, she just needs to see a photo ID, any gov't issued ID will work. Technically my valet key which will allow her to open my car and read my VIN and possibly authenticate it against a DMV database should also work, but that's probably overkill.
There are good uses for OpenId, OAuth and Federated logins, but as developers we need to understand when and where we should use each of them.
http://en.wikipedia.org/wiki/OAuth#OpenID_vs._pseudo-authentication_using_OAuth