1:

External authentication/authorization systems (as implemented by Facebook, Live, Google and several others) typically work as follows:

1: user requests access to a secured service

2: service redirects user to auth provider's login window

3: auth provider gives a security token (a temporary key of sorts) to client and redirects client back to the secured service

4: client passes the security token to the secured service as proof of identity (and feature authorization)

5: secure service verifies the token so as to ensure that the user did not generate it by him/herself, that it has not expired, and whatnot

6: at secure service, if token is successfully verified and token contains necessary claims (facts about the user), then proceed with secured functionality

Again, typically, one of the claims of the token is the user id given by the authentication service. This id, along with the auth provider id, is what you'd store (at the very least) in your own authorized user database. You can also typically get the user name from one of the claims of the token.

Do note that your application ("secure service" in the preceding list) needs to be registered to the auth provider so that they can generate tokens that are uniquely usable by your application only. If this step were to be omitted, any token issued by the provider (think many other applications) could be used to authorize access to your application, which is usually highly undesirable.

2:

If you're on Windows Server, try out Entity Framework (for database abstraction) and Identity Framework (for convenient access token handling). Others can probably give recommendations for other server platforms.