How to make it extensible
First you should notice all these api's use the same mechanism for logging in. They all use OAuth for their authentication. This you need to leverage by starting with a general OAuth library. Don't use their own libraries for authentication, these will be unusable for other providers. If you get the hang of OAuth2 it is quite easy to add more providers.
You need unfortunately two of them, because twitter still hasn't jumped the OAuth2 bandwagon.
OAuth needs you to create an interface for the authenticating party. The tokens will be exchanged server to server. Create one entry point, which can handle all the communication.
The token should be stored in a separate table from your account, this is because their can be multiple tokens and multiple linked profiles. Some services give you two tokens, one of them is a refresh token.
Now you design an interface, which encapsulates the other functionality you need. I would personally setup a separate REST-service for this. This way you can easily extend the authentication to other places.
Some services use JSON to communicate, other go for XML etc. For the front user you need to unify them all. This is a pretty painful process, but it is possible to derive some common grounds here.
Another problem here, is that not all the services provide the same functionality. This can mean, that your services cannot provide the full API as you specified. You need to have a strategy here, which let the application gracefully downgrade.
This all will ensure you can easily add new 3rd party providers.
The tokens are limited in time, thus you need a couple of cron jobs, which can check if the token is still usable, otherwise you have to delete it. You can also refresh a token by this mechanism.
It sometimes happens, that an user retracts the token. Be ready for this.
If you have this design, you need to think about the data you need. This follows partly from your just created interface. Design some tables for this and look if the data is actually retrievable. Some services don't let you grab a lot of data. You should also take into account, that the more data you need, the heftier the privacy messages become. So be modest in your needs, otherwise users won't use it.
For extra verification, you can store the profiles in a separate, but linked table to your users. This will provide you with a lot more information about someone.
Also check your local laws, for some data you need extra precautions.
Don't make the fault where you don't create an account on your own services. If the user gets banned from facebook, he will effectively be unable to login on your service. This is a situation you don't want to create. This is often overlooked.