Chances are you will need to roll your own if you don't like the idea of embedding a small webbrowser directly in the game or opening up one. You will need to setup your own server (but you would probably need to do that anyway).
For rolling your own have a look at how web pages normally handle authentication.
Your not going to get away with having them not create an account (otherwise what are they logging into), you can however make it very quick and painless. If there is no account with that username, ask if they want to register it and then just do it without asking a bunch of things like emails and so on (Reddit does that). If you want to ensure they can recover their password then make the email optional.
Your not going to find a 3rd party login system that won't require to visit to their stuff to authorize things. Since the alternative would require the username/password to be entered in every single 3rd party program, it would be trivial for a malicious developer to capture that information (of course that's possible anyway since they could fake something like a Google login prompt).
A few important key points if you setup your own:
* Firstly make sure everything is done over encryption (SSL/TLS). This will stop man in the middle attacks. You will need to use a signed certificate. Either use the main certificate authorities (StartSSL does them for free). Alternatively if you don't want to bother with the certificate authorities you can self sign and ship the public side of your certificate as part of the game executable. If you don't use a cert then someone can do things like setting up a fake DNS on large lans and steal logins by acting as a proxy between the player and your servers.
Make sure passwords are encrypted hashes in the database, not in some plain text form. If you don't do this you risk the chance of getting hacked and having everyones passwords stolen. Even if you force everyone to reset their passwords there is a good chance many (most) of them are stupid enough to have used password for multiple places. For example their email that is often used to send them new passwords for just about every other account they login with. This would be a massive PR nightmare.
Use randomly generated salt, unique for each login stored with the account. This stops people from reversing the hashes by using precomputed databases.
Use multiple rounds of encryption. Even with salt it's possible to break a few accounts in a time frame.
Try not to build as much of this as possible, chances are you will mess it up in a big way. Look at bcrypt/scrypt for decent password hashing functions that include multiple rounds designed to scale difficulty with modern hardware. If possible find a complete password storage library that has been prewritten for your language/platform. Things that have more use have more testing and are often designed by a team of people much smarter than you are. Assume your own programming is horrible and will get hacked, then program in a way to ensure if that does happen it's not a major disaster. You can't afford to cut corners here just because something is hard, or you think that a particular problem is unlikely to occur, or because your user base isn't going to be that big and you can fix it later if it grows.
Make sure your random numbers are generated in a cryptographically secure way. The default random function in your programming language isn't likely to be.
Generate a random token that is sent to the player, that authenticates them. If you wan't to offer a 'remember password' function it might be better to just store the token rather than the password. That way if someone has access to the players computer they can't steal their password just the token that can be reset. You will need to keep track of all active tokens and there may be multiple per player. Time out the tokens eventually.
It's a good idea to make a very minimal login server that runs on a separate server from your other components. Since this is where all the security is if your main game server/website is hacked in your login database won't be compromised. Make sure you log everything.
If you don't want your own host, you can look at Google App Engine and similar solutions. It's even free for small usage cases.
It might be worth looking at how XMPP handles authentication. Of course the whole standard is somewhat over engineered for a whole game. But it does do chat as well. XMPP itself could serve as a authentication system but it would be kind of a hacky use of it. I'm not sure if Google would allow that kind of use with GTalk since they probably don't like 3rd party programs asking for password. You could operate your own XMPP server and get chat, authentication and encryption, but you would need a XMPP client built into your game.
OAuth isn't too bad, it only would require the user to use the webinterface one time to authorize the program to be linked and it works with Google/Facebook and probably quite a few others and it does mean you no longer have to bother with running your own server.
BrowserID is another new alternative. But it's also a browser based system.